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

[Sven Schreiber]

I agree with everything in your post, so I'm really happy you're a
central figure of numpy!

As for rand(), ones() etc.: I don't mind (too much) the double pair of
parentheses in ones((5,5)), but I find Robert's proposal in an earlier
thread ("If you want a function that takes tuples, use
numpy.random.random().") a little impractical, because I'm mostly one of
the prototypers as you defined them.

I've come to realize that for me (and from what I read, for Bill as
well) rand() is not adding convenience because we cannot settle on any
habit (neither single nor double pairs of parentheses) and therefore we
 continue to get one or the other wrong when we're not paying full
attention.

Anything that allows me to develop a consistent habit is fine with me!

Thanks much,
Sven

Travis Oliphant schrieb:
> Hmmm.....   One thing that bothers me is that it seems that those 
> arguing *against* this behavior are relatively long-time users of Python 
> while those arguing *for* it are from what I can tell somewhat new to 
> Python/NumPy.  I'm not sure what this means.
> 
> Is the current behavior a *wart* you get used to or a clear *feature* 
> providing some  gain in programming efficiency. 
> 
> If new users complain about something, my tendency is to listen openly 
> to the discussion and then discourage the implementation only if there 
> is a clear reason to.
> 
> With this one, I'm not so sure of the clear reason.   I can see that 
> "program parsers" would have a harder time with a "flexible" calling 
> convention.  But, in my calculus, user-interface benefit outweighs 
> programmer benefit (all things being equal).
> 
> It's easy as a programmer to get caught up in a very rigid system when 
> many users want flexibility.
> 
> I must confess that I don't like looking at ones((5,5)) either.  I much 
> prefer ones(5,5) or even ones([5,5]). 
> 
> But perhaps what this shows is something I've heard Robert discuss 
> before that ihas not received enough attention.   NumPy really has at 
> least two "users"  1) application developers and 2) prototype developers 
> (the MATLAB crowd for lack of a better term). 
> 
> These two groups usually want different functionality (and in reality 
> most of us probably fall in both groups on different occasions).  The 
> first clamors for more rigidity and conformity even at the expense of 
> user interfaces.  These people usually want
> 
> 1) long_but_explanatory_function names
> 2) rigid calling syntax
> 3) strict name-space control
> 
> The second group which wants to get something prototyped and working 
> quickly wants
> 
> 1) short easy-to-remember names
> 2) flexible calling syntax
> 3) all-in-one name-space control
> 
> My hypothesis is that when you first start with NumPy (especially with a 
> MATLAB  or IDL history) you seem to start out in group 2 and stay there 
> for quick projects. Then, as code-size increases and applications get 
> larger, you become more like group 1. 
> 
> I think both groups have valid points to make and both styles can be 
> useful and one point or another. Perhaps, the solution is the one I have 
> barely begun to recognize, that others of you have probably already seen.
> 
> A) Make numpy a good "library" for group 1.
> B) Make a shallow "name-space" (like pylab) with the properties of group 2.
> 
> Perhaps a good solution is to formalize the discussion and actually 
> place in NumPy a name-space package much like Bill has done privately.
> 
> -Travis
> 
> 
> 
> 
> 
> 
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>