[Numpy-discussion] Created NumPy 1.7.x branch
Tue Jun 26 09:52:42 CDT 2012
On Jun 26, 2012, at 9:00 AM, Charles R Harris wrote:
> On Mon, Jun 25, 2012 at 9:10 PM, Ondřej Čertík <firstname.lastname@example.org> wrote:
> On Mon, Jun 25, 2012 at 7:38 PM, Fernando Perez <email@example.com> wrote:
> > On Mon, Jun 25, 2012 at 6:39 PM, Travis Oliphant <firstname.lastname@example.org> 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:
> 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):
> 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.
This is not accurate, Charles. Please stop trying to dredge up old history you don't know the full story about and are trying to create an alternate reality about. It doesn't help anything and is quite poisonous to this mailing list. You have a narrative about the past that seems very different from mine --- and you apparently blame me personally for all that is wrong with NumPy. This is not a helpful perspective and it just alienates us further and is a very polarizing perspective. This is not good for the community nor for our ability to work productively together. I hope that it is not a permanent reality and you will find a way to see things in a different light.
> 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?
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion