>
> And mark my words, if we make rand() polymorphic,
>
we will get just as many newbies coming to the list asking why ones(3, 4)
>
doesn't work.
>
I think you're probably right there, at least for Matlab converts. Matlab
allows either way of calling for all of rand, ones, zeros, eye, and in
general tries to make *every* function accept *any* possible combination of
arguments that might make sense. So having rand() accept both, but not the
others, will undoubtedly be unexpected to Matlab users. And the argument
against funky overloading will be weaker since they'll be able to say "well
rand() does it? why can't ones()?"
Fortunately it's pretty easy to define one's own custom versions of these
little helper functions to make them just the way you like them. Or for
rand(), just "from numpy.random import uniform_sample as rand" if that's the
version you like.
This isn't a panacea, but you can then collect all these into a little
customization module, say "mynum.py" which is somewhere on your PYTHONPATH,
and then set up all your customizations with a "from mynum import *"
You can even go further if you wish and define the PYTHONSTARTUP environment
variable to point to a file that does "from mynum import *" so that every
time you start up the interactive interpreter you have your definitions
there already.
I'm sure this is all well known to you long-time Python'ers out there, but I
thought I'd mention it since there are probably other numpy users out there
who, like me, are pretty new to Python.
--bb
|
