On Sat, Apr 4, 2015 at 10:38 PM, Nathaniel Smith <n...@pobox.com> wrote: > > On Apr 4, 2015 4:12 AM, "Todd" <toddr...@gmail.com> wrote: > > > > > > On Apr 4, 2015 10:54 AM, "Nathaniel Smith" <n...@pobox.com> wrote: > > > > > > Core python broke backcompat on a regular basis throughout the python > > > 2 series, and almost certainly will again -- the bar to doing so is > > > *very* high, and they use elaborate mechanisms to ease the way > > > (__future__, etc.), but they do it. A few months ago there was even > > > some serious consideration given to changing py3 bytestring indexing > > > to return bytestrings instead of integers. (Consensus was > > > unsurprisingly that this was a bad idea, but there were core devs > > > seriously exploring it, and no-one complained about the optics.) > > > > There was no break as large as this. In fact I would say this is even a larger change than any individual change we saw in the python 2 to 3 switch. The basic mechanics of indexing are just too fundamental and touch on too many things to make this sort of change feasible. > > I'm afraid I'm not clever enough to know how large or feasible a change is without even seeing the proposed change.
It doesn't take any cleverness. The change in question was to make the default indexing semantics to orthogonal indexing. No matter the details of the ultimate proposal to achieve that end, it has known minimum consequences, at least in the broad outline. Current documentation and books become obsolete for a fundamental operation. Current code must be modified by some step to continue working. These are consequences inherent in the end, not just the means to the end; we don't need a concrete proposal in front of us to know what they are. There are ways to mitigate these consequences, but there are no silver bullets that eliminate them. And we can compare those consequences to approaches like Jaime's that achieve a majority of the benefits of such a change without any of the negative consequences. That comparison does not bode well for any proposal. -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
