<div dir="ltr">On Thu, Apr 9, 2015 at 8:07 AM, Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br>><br>> On Do, 2015-04-09 at 08:50 +0200, Sebastian Berg wrote:<br><br>> > 3. I do not know if it possible or useful, but I could imagine a module<br>> > wide switch (similar to __future__ imports) to change the default<br>> > indexing behaviour.<br>><br>> OK, my suggestion.... But actually I do not know if I like it all that<br>> much (nor if it can be done) since 1. and 2. seem to me like enough. But<br>> if someone feels strongly about fancy indexing being bad, I wanted to<br>> point out that there may be ways to go down the road to "switch" numpy<br>> without actually switching.<br><br>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.<div><br></div><div>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.<div><br>--<br>Robert Kern</div></div></div>