[Numpy-discussion] NEP 21: Simplified and explicit advanced indexing (original) (raw)

Sebastian Berg sebastian at sipsolutions.net
Tue Jun 26 03:57:07 EDT 2018

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 at gmail.co_ _m> wrote: > > I don't think it should be relegated to the "officially > discouraged" ghetto of .legacyindex > > 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, 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. I see a possible problem with code that has to work on different numpy versions, but only in meaning we need to delay deprecations.

The only thing I could imagine where this might happen is if you forward someone elses indexing objects and different users are used to different results. Otherwise, there is mostly one case which would get annoying, and that is arr[:, rr, cc] since arr.vindex[:, rr, cc] would not be exactly the same. Because, yes, in some cases the current logic is convenient, just incredibly surprising as well.

NumPy-Discussion mailing list NumPy-Discussion at python.org https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/e26ff80f/attachment-0001.sig>

More information about the NumPy-Discussion mailing list