On Tue, 2018-06-26 at 04:01 -0400, Hameer Abbasi 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.
Could you list some examples what you would need? We can expose some of the internals, or maybe even provide funcs to map e.g. oindex to vindex or vindex to plain indexing, etc. but it would be helpful to know what downstream actually might need. For all I know the things that you are thinking of may not even exist... - Sebastian > > Best Regards, > Hameer Abbasi > Sent from Astro 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+numpy@gma > > il.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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
