[Numpy-discussion] Args for ones, zeros, rand, eye, ones, empty (possible 1.0 change?)

Bill Baxter wbaxter at gmail.com
Mon Jul 3 01:59:51 CDT 2006

On 7/3/06, Alan G Isaac <aisaac at american.edu> wrote:
> Your primary argument against changing the API, as far as
> I can see, is that allowing *both* the extant behavior and
> the numpy consistent behavior will result in confusing code.
> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3150643
> Is this a knock-down argument?  I think not.

In particular the argument was that it would make for code that's confusing
for users to read.  I.e. in some places the users see 'rand(2,2,3)' and in
other places 'rand((2,2,3))'.  I really don't see anything confusing about
that.  There's only one interpretation of either of those that makes sense.
If there's any confusion issue I think it's more likely to come from looking
at the source code of rand() itself.  But even that is pretty minor given a
few minutes to write a some comments about what's going on.

Personally I think allowing the separate argument variations on these few
methods would be a good thing.  It makes ones() and zeros() more like
Matlab's for one.  But also it just looks cleaner to say ones(2,3,5)  than
it does to say ones((2,3,5)).  I understand the general objections to it.
-- It's kind of hacky with the *args,*kwargs;
-- it leads to "more that one way to do it";
-- makes the implementation code a little harder to write and read (but I
say it makes user code EASIER to write/read);
-- can make IDEs confused (PyCrust at least tries suggests *args,**kwags as
arguments); and
-- isn't always possible to have both tuple and separate shape values if the
arg after the shape arguments is also a number, like func(shape, num=0)

But in this case, since these are functions that are both really simple and
get a lot of use, I think it's worth it to make them easier to use, even if
it uglifies the implementation.

At this point since I've already got an implementation of this which works
great for everything I want it to do, I'm not really going to be affected by
whatever numpy decides to go with.  I'll just wrap numpy with my functions.
Making my own wrapper layer for my favorite numpy customizations was
something I'd been meaning to do anyway.  But I do think this is a change
that would make numpy more user friendly.  And as Alan points out, it seems
to be a repeat discussion.  I suspect that's because they are all functions
newbies will encounter early on when they're trying to understand the logic
behind numpy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20060703/a8c4a6e2/attachment.html 

More information about the Numpy-discussion mailing list