(original) (raw)
On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Tue, 2018-06-26 at 17:30 +1000, Andrew Nelson wrote:
\> On Tue, 26 Jun 2018 at 17:12, Eric Wieser <wieser.eric+numpy@gmail.co
\> m> wrote:
\> > > I don't think it should be relegated to the "officially
\> > discouraged" ghetto of \`.legacy\_index\`
\> >
\> > The way I read it, the new spelling lof that would be the explicit
\> > but not discouraged \`image.vindex\[rr, cc\]\`.
\> >
\>
\> If I'm understanding correctly what can be achieved now by \`arr\[rr,
\> cc\]\` would have to be modified to use \`arr.vindex\[rr, cc\]\`, which is
\> a very large change in behaviour. I suspect that there a lot of
\> situations out there which use \`arr\[idxs\]\` where \`idxs\` can mean one
\> of a range of things depending on the code path followed. If any of
\> those change, or a mix of nomenclatures are required to access the
\> different cases, then havoc will probably ensue.
Yes, that is true, but I doubt you will find a lot of code path that
need the current indexing as opposed to vindex here,
That's probably true! But I think it's besides the point. I'd wager that most code paths that will use .vindex would work perfectly well with current indexing, too. Most of the time, people aren't getting into the hairy corners of advanced indexing.
Adding to the toolbox is great, but I don't see a good reason to take out the ones that are commonly used quite safely.
and the idea was
to have a method to get the old behaviour indefinitely. You will need
to add the \`.vindex\`, but that should be the only code change needed,
and it would be easy to find where with errors/warnings.
It's not necessarily hard; it's just churn for no benefit to the downstream code. They didn't get a new feature; they just have to run faster to stay in the same place.
Robert Kern