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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion