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

[Travis O. <oli...@ie...>]

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