On Tue, 2018-06-26 at 22:26 -0700, Robert Kern wrote: > On Tue, Jun 26, 2018 at 10:21 PM Juan Nunez-Iglesias <jni.soma@gmail. > com> wrote: > > Let me start by thanking Robert for articulating my viewpoints far > > better than I could have done myself. I want to explicitly flag the > > following statements for endorsement: > > > > > 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. > > > In the post-NEP .oindex/.vindex order, everyone can get the > > > behavior that they want. Your argument for deprecation is now > > > just about what the default is, the semantics that get pride of > > > place with the shortest spelling. I am sympathetic to the feeling > > > like you wish you had a time machine to go fix a design with your > > > new insight. But it seems to me that just changing which > > > semantics are the default has relatively attenuated value while > > > breaking compatibility for a fundamental feature of numpy has > > > significant costs. Just introducing .oindex is the bulk of the > > > value of this NEP. Everything else is window dressing. > > > 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). > > > > I would offer the exception of trailing slices to this statement, > > though: > >
OK, sounds fine to me, I see that we just can't start planning for a possible long term future yet. I personally do not care really what the warnings itself say for now (Deprecation or not), larger packages will have to avoid them in any case though. But I guess we have a consent on a certain amount of warnings (probably will have to see how much they actually appear) and then can revisit in a longer while. - Sebastian > > In [1]: from skimage import data > > In [2]: astro = data.astronaut() > > In [3]: astro.shape > > Out[3]: (512, 512, 3) > > > > In [4]: rr, cc = np.array([1, 3, 3, 3]), np.array([1, 8, 9, 10]) > > In [5]: astro[rr, cc].shape > > Out[5]: (4, 3) > > > > In [6]: astro[rr, cc, :].shape > > Out[6]: (4, 3) > > > > This does exactly what I would expect. > > > > Yup, sorry, I didn't mean those. I meant when there is an explicit > slice in between index arrays. (And maybe when index arrays follow > slices; I'll need to think more on that.) > > > Going back to the motivation for the NEP, I think this bit, > > emphasis mine, is crucial: > > > > > > the existing rules for advanced indexing with multiple array > > > > indices are typically confusing to both new, **and in many > > > > cases even old,** users of NumPy > > > > I think it is ok for advanced indexing to be accessible to advanced > > users. I remember that it took me quite a while to grok NumPy > > advanced indexing, but once I did I just loved it. > > > > I also like that this syntax translates perfectly from integer > > indices to float coordinates in `ndimage.map_coordinates`. > > > > > I'll go on record as saying that array-likes should respond to > > > `a[rr, cc]`, as in Juan's example, with the current behavior. And > > > if they don't, they don't deserve to be operated on by skimage > > > functions. > > > > (I don't think of us highly enough to use the word "deserve", but I > > would say that we would hesitate to support arrays that don't use > > this convention.) > > > > Ahem, yes, I was being provocative in a moment of weakness. May the > array-like authors forgive me. > > _______________________________________________ > 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
