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

[Ralf Gommers]

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

> On Sat, Apr 4, 2015 at 2:15 AM, Robert Kern <robert.kern at gmail.com> wrote:
> > On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers <ralf.gommers at gmail.com>
> >> wrote:
> >> >
> >> > On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith <njs at pobox.com>
> wrote:
> >
> >> >> 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?).
> >>
> >> I agree 100% that we should and do care strongly about backwards
> >> compatibility. But you're saying in one sentence that we should tell
> >> people that we won't consider backcompat breaks, and then in the next
> >> sentence that of course we actually will consider them (even if we
> >> almost always reject them). Basically, I think saying one thing and
> >> doing another is not a good way to build people's trust.
> >
> > There is a difference between politely considering what proposals people
> > send us uninvited and inviting people to work on specific proposals.
> That is
> > what Ralf was getting at.
>
> I mean, I get that Ralf read my bit quoted above and got worried that
> people would read it as "numpy core team announces they don't care
> about backcompat", which is fair enough. Sometimes people jump to all
> kinds of conclusions, esp. when confirmation bias meets skim-reading
> meets hastily-written emails.
>
> But it's just not true that I read people's proposals out of
> politeness; I read them because I'm interested, because they might
> surprise us by being more practical/awesome/whatever than we expect,
> and because we all learn things by giving them due consideration
> regardless of the final outcome.


Thanks for explaining, good perspective.


> So yeah, I do honestly do want to see
> people work on specific proposals for important problems (and this
> indexing thing strikes me as important), even proposals that involve
> breaking backcompat. Pretending otherwise would still be a lie, at
> least on my part. So the distinction you're making here doesn't help
> me much.
>

A change in semantics would help already. If you'd phrased it for example
as:

  "I'd personally be interested in seeing a description of what changes,
including backwards-incompatible ones, would need to be made to numpy
indexing behavior to resolve this situation. We could learn a lot from such
an exercise.",

that would have invited the same investigation from interested people
without creating worries about Numpy stability. And without potentially
leading new enthusiastic contributors to believe that this is an
opportunity to make an important change to Numpy: >99.9% chance that they'd
be disappointed after having their well thought out proposal rejected.

Cheers,
Ralf



> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150404/73f2cc25/attachment.html>