[Numpy-discussion] Non-meta indexing improvements discussion

[Robert Kern]

On Thu, Apr 9, 2015 at 8:07 AM, Sebastian Berg <sebastian at sipsolutions.net>
wrote:
>
> On Do, 2015-04-09 at 08:50 +0200, Sebastian Berg wrote:

> > 3. I do not know if it possible or useful, but I could imagine a module
> > wide switch (similar to __future__ imports) to change the default
> > indexing behaviour.
>
> OK, my suggestion.... But actually I do not know if I like it all that
> much (nor if it can be done) since 1. and 2. seem to me like enough. But
> if someone feels strongly about fancy indexing being bad, I wanted to
> point out that there may be ways to go down the road to "switch" numpy
> without actually switching.

I can't think of a way to actually make that work (I can list all the ways
I thought of that *don't* work if anyone insists, but it's a tedious dead
end), but it also seems to me to be a step backward. Assuming that we have
both .ortho_ix and .fancy_ix to work with, it seems to me that the
explicitness is a good thing. Even if in this module you only want to
exploit one of those semantics, your module's readers live in a wider
context where both semantics play a role. Moving your marker of "this is
the non-default semantics I am using" to some module or function header
away from where the semantics are actually used makes the code harder to
read.

A newish user trying to read some nontrivial indexing code may come to the
list and ask "what exactly is this expression doing here?" and give us just
the line of code with the expression (anecdotally, this is usually how this
scenario goes down). If we have to answer "it depends; is there an
@ortho_indexing decorator at the top of the function?", that's probably a
cure worse than the disease. The properties are a good way to provide
googleable signposts right where the tricky semantics are being used.

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150409/e5a3c918/attachment.html>