[Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #406 - 13 msgs

[Greg Kochanski]

> Are you opposed to anything going inside the [] operator to help indicate
> how the objects inside should be interpreted

I'm opposed to overloading any operator so that it becomes confusing.
Confusion is generated when a look at a small part of code
(a line or two) does not tell you what the code is doing.

This is a real problem for languages like Python and Perl, where
any variable can contain any data, IF the code behaves in
different ways, dependent on the data type.

"Different" is defined by the user, and it roughly translates
into the amount of coffee you have to drink to fix the code,
if the input data changes it's type.

> > Besides, you know some idiot is going to eventually write
> > code that looks like this:
> >
> > def access(a, b, x):
> >       return a[b, x]  # I think that a must be a 2-D array...
> >
> > # 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.

I assumed you were proposing a magic second argument to [] that would
cause the first argument to be interpreted differently.

If so, I think that's a bad idea from a human-interface point of view,
because

(a) To a person who only uses Numpy occasionally, it is not obvious
that an argument is "magic".   That makes the code less readable.

(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
magic 
or not.

Using an explicit function or method call fixes (a) by telling the naive
user
that "this is not normal array access here."
It also fixes (b) by making it more obvious that fancy stuff is going
on.