I like the proposal generally. NumPy could use a good orthogonal indexing method and a vectorized-indexing method is fine too.
Robert Kern is spot on with his concerns as well. Please do not change what arr[idx] does except to provide warnings and perhaps point people to new .oix and .vix methods. What indexing does is documented (if hard to understand and surprising in a particular sub-case). There is one specific place in the code where I would make a change to raise an error rather than change the order of the axes of the output to provide a consistent subspace. Even then, it should be done as a deprecation warning and then raise the error. Otherwise, just add the new methods and don't make any other changes until a major release. -Travis On Tue, Jun 26, 2018 at 2:03 AM Hameer Abbasi <einstein.edi...@gmail.com> wrote: > I second this design. If we were to consider the general case of a tuple > `idx`, then we’d not be moving forward at all. Design changes would be > impossible. I’d argue that this newer model would be easier for library > maintainers overall (who are the kind of people using this), reducing > maintenance cost in the long run because it’d lead to simpler code. > > I would also that the “internal” classes expressing outer as vectorised > indexing etc. should be exposed, for maintainers of duck arrays to use. God > knows how many utility functions I’ve had to write to avoid relying on > undocumented NumPy internals for pydata/sparse, fearing that I’d have to > rewrite/modify them when behaviour changes or I find other corner cases. > > Best Regards, > Hameer Abbasi > Sent from Astro <https://www.helloastro.com> for Mac > > On 26. Jun 2018 at 09:46, Robert Kern <robert.k...@gmail.com> wrote: > > > On Tue, Jun 26, 2018 at 12:13 AM Eric Wieser <wieser.eric+nu...@gmail.com> > 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]`. >> > > Okay, I missed that the first time through. I think having more > self-contained descriptions of the semantics of each of these would be a > good idea. The current description of `.vindex` spends more time talking > about what it doesn't do, compared to the other methods, than what it does. > > Some more typical, less-exotic examples would be a good idea. > > > 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. > > -- > Robert Kern > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
