[Numpy-discussion] Advanced indexing: "fancy" vs. orthogonal

[Ralf Gommers]

On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith <njs at pobox.com> wrote:

>
> But, the real problem here is that we have two different array duck
> types that force everyone to write their code twice. This is a
> terrible state of affairs! (And exactly analogous to the problems
> caused by np.ndarray disagreeing with np.matrix & scipy.sparse about
> the the proper definition of *, which PEP 465 may eventually
> alleviate.) IMO we should be solving this indexing problem directly,
> not applying bandaids to its symptoms, and the way to do that is to
> come up with some common duck type that everyone can agree on.
>
> Unfortunately, AFAICT this means our only options here are to have
> some kind of backcompat break in numpy, some kind of backcompat break
> in pandas, or to do nothing and continue indefinitely with the status
> quo where the same indexing operation might silently return different
> results depending on the types passed in. All of these options have
> real costs for users, and it isn't at all clear to me what the
> relative costs will be when we dig into the details of our various
> options.


I doubt that there is a reasonable way to quantify those costs, especially
those of breaking backwards compatibility. If someone has a good method,
I'd be interested though.


> So I'd be very happy to see worked out proposals for any or
> all of these approaches. It strikes me as really premature to be
> issuing proclamations about what changes might be considered. There is
> really no danger to *considering* a proposal;


Sorry, I have to disagree. Numpy is already seen by some as having a poor
track record on backwards compatibility. Having core developers say
"propose some backcompat break to how indexing works and we'll consider it"
makes our stance on that look even worse. Of course everyone is free to
make any technical proposal they deem fit and we'll consider the merits of
it. However I'd like us to be clear that we do care strongly about
backwards compatibility and that the fundamentals of the core of Numpy
(things like indexing, broadcasting, dtypes and ufuncs) will not be changed
in backwards-incompatible ways.

Ralf

P.S. also not for a possible numpy 2.0 (or have we learned nothing from
Python3?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150404/832bc925/attachment.html>