(original) (raw)

On Tue, Jun 26, 2018 at 12:46 AM Robert Kern <robert.kern@gmail.com> wrote:
On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser <wieser.eric+numpy@gmail.com> wrote:
> I would reserve warnings for the cases where the current behavior is something no one really wants, like mixing slices and integer arrays.

These are the cases that would only be available under \`legacy\_index\`.

I'm still leaning towards not warning on current, unproblematic common uses. It's unnecessary churn for currently working, understandable code. I would still reserve warnings and deprecation for the cases where the current behavior gives us something that no one wants. Those are the real traps that people need to be warned away from.

If someone is mixing slices and integer indices, that's a really good sign that they thought indexing behaved in a different way (e.g. orthogonal indexing).

If someone is just using multiple index arrays that would currently not give an error, that's actually a really good sign that they are using it correctly and are getting the semantics that they desired. If they wanted orthogonal indexing, it is \*really\* likely that their index arrays would \*not\* broadcast together. And even if they did, the wrong shape of the result is one of the more easily noticed things. These are not silent errors that would motivate adding a new warning.

Of course, I would definitely support adding more information to the various IndexError messages to point people to \`.oindex\` and \`.vindex\`. I think that would guide more people to correct their code than adding a new warning to code that currently executes (which is likely not erroneous), and it would cause no churn.
--
Robert Kern