On 7/3/06, Alan G Isaac <aisaac@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.