[Numpy-discussion] Created NumPy 1.7.x branch

[Charles R Harris]

On Mon, Jun 25, 2012 at 9:10 PM, Ondřej Čertík <ondrej.certik at gmail.com>wrote:

> On Mon, Jun 25, 2012 at 7:38 PM, Fernando Perez <fperez.net at gmail.com>
> wrote:
> > On Mon, Jun 25, 2012 at 6:39 PM, Travis Oliphant <travis at continuum.io>
> wrote:
> >>
> >> On Jun 25, 2012, at 7:21 PM, Fernando Perez wrote:
> >
> >>
> >> For context, consider that for many years, the word "gratuitous" has
> been used in a non-derogatory way in the Python ecosystem to describe
> changes to semantics and syntax that don't have benefits significant enough
> to offset the pain it will cause to existing users.    That's why I used
> the word.   I am not trying to be derogatory.   I am trying to be clear
> that we need to respect existing users of NumPy more than we have done from
> 1.5 to 1.7 in the enthusiasm to make changes.
> >>
> >
> > For reference, here's the (long) thread where this came to be:
> >
> > http://mail.scipy.org/pipermail/scipy-dev/2009-October/012958.html
> >
> > It's worth noting that at the time, the discussion was for an addition
> > to *scipy*, not to numpy.  I don't know when things were moved over to
> > numpy.
> >
> >
> >> Working on the NumPy code base implies respecting the conventions that
> are already in place --- not just disregarding them and doing whatever we
> want.     I'm not really sure why I have to argue the existing users point
> of view so much recently.    I would hope that all of us would have the
> perspective that the people who have adopted NumPy deserve to be treated
> with respect.    The changes that grate on me are the ones that seem to
> take lightly existing users of NumPy.
> >>
> >
> > I certainly appreciate the need to not break user habits/code, as we
> > struggle with the very same issue in IPython all the time.  And
> > obviously at this point numpy is 'core infrastructure' enough that
> > breaking backwards compatibility in any way should be very strongly
> > discouraged (things were probably a bit different back in 2009).
> >
> >>> I know that this particular issue grates you quite a bit, but I urge
> >>> you to be fair in your appreciation of how it came to be: through the
> >>> work of well-intentioned and thoughtful (but not omniscient) people
> >>> when you weren't participating actively in numpy development.
> >>
> >> I'm trying very hard to be fair --- especially to changes like this.
>  What grates me are changes that affect our user base in a negative way ---
> specifically by causing code that used to work to no longer work or create
> alterations to real conventions.  This kind of change is just not
> acceptable if we can avoid it.   I'm really trying to understand why others
> do not feel so strongly about this, but I'm not persuaded by what I've
> heard so far.
> >
> > I just want to note that I'm not advocating for *any*
> > backwards-compatibility breakage in numpy at this point... I was just
> > providing context for a discussion that happened back in 2009, and in
> > the scipy list.  I certainly feel pretty strongly at this point about
> > the importance of preserving working code *today*, given the role of
> > numpy at the 'root node' of the scipy ecosystem tree and the size of
> > said tree.
>
> I think that everybody strongly agrees that backward incompatible
> changes should not be made.
>
> Sometimes it can be more subtle,
> see for example this numpy bug report in Debian:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589835
>
> and read the dozens of emails that it generated, e.g.
> http://lists.debian.org/debian-python/2010/07/msg00048.html, and so
> on. I've been hit by this problem too, that's why I remember it --
> suddenly many packages that depend on NumPy stopped working in a
> subtle way and I had to spent hours figuring out what went wrong and
> that the problem is not in h5py, but actually that NumPy has changed
> its ABI, or more precisely the problem is described here (some new
> members were added to a C datastructure):
> http://lists.debian.org/debian-python/2010/07/msg00045.html
> I am sure that this ABI change had to be done and there were good
> reasons for it and this particular change probably even couldn't have
> been avoided. But nevertheless it has caused headaches to a lot of
> people downstream. I just looked into the release notes for NumPy
> 1.4.0 and didn't find this change nor how to fix it in there. I am
> just posting this as a particular, concrete, real life example of
> consequences for the end users.
>

Let us note that that problem was due to Travis convincing David to include
the Datetime work in the release against David's own best judgement. The
result was a delay of several months until Ralf could get up to speed and
get 1.4.1 out. Let us also note that poly1d is actually not the same as
Matlab poly1d.


>
> My understanding is that Travis is simply trying to stress "We have to
> think about the implications of our changes on existing users." and
> also that little changes (with the best intentions!) that however mean
> either a breakage or confusion for users (due to historical reasons)
> should be avoided if possible. And I very strongly feel the same way.
> And I think that most people on this list do as well.
>
> But sometimes I guess mistakes are made anyway. What can be done to
> avoid similar issues like with the polynomial order in the future?
>
>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120626/c8dd8943/attachment.html>