[Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs
oliphant at ee.byu.edu
Wed Mar 6 17:42:03 CST 2002
> > > # 1000 lines later...
> > > access(a, _I) # Whoops all my assumptions were wrong...
> > I have no idea, what your concern is here. This would result in an error
> > currently and under the scheme I suggested.
> Then, perhaps you should explain again.
No you grasp it, I think your example contained errors (you only called
access with two arguments rather than the three expected by the interface,
Thank you for explaining your concerns in more detail, below.
> If so, I think that's a bad idea from a human-interface point of view,
> (a) To a person who only uses Numpy occasionally, it is not obvious
> that an argument is "magic". That makes the code less readable.
That can be a "problem", but it is a "problem" in many languages that
currently are in wide-spread use in numerical computing.
Apparently, the convenience outweighs the perceived concern. Currently,
whenever you use variables to index arrays you know that something is
going on that you can't see by just looking at it (i.e. something fancy).
For example, you can currently write
and have this do different things depending on whether b is a sequence or
a slice object or an integer. I don't see how the addition of another
check drastically changes the current state.
I actually think the flexiblility is a good thing and it makes Python very
It comes down to trusting people to write code you can understand (if
you have any reason to interface with them in the first place).
My programming philosophy definitely leans toward empowering people, even
if it means they can do something stupid later.
> (b) It is possible to write code where one can pass in the "magic" value
> in a variable, and no simple inspection of the code will tell if it is
> or not.
This is already possible (and frequently used), now.
> Using an explicit function or method call fixes (a) by telling the naive
> that "this is not normal array access here."
You are focusing on the naive user at the expense of convenience for the
power user. I think this is appropriate sometimes, but not when we are
talking about a language that somebody will use constantly for many years
to implement their daily work.
I think it makes the code much more readable and therefore understandable
and maintainable to overload the  operator rather than use a method
MATLAB's big advantage over Numeric Python right now is that it allows
this sort of indexing already which Python users currently have to
implement using a function call.
> It also fixes (b) by making it more obvious that fancy
stuff is going > on.
Whenever you see
a[b] instead of
you alread know that something fancy is going on... Nothing would change
More information about the Numpy-discussion