[Numpy-discussion] Created NumPy 1.7.x branch

[Travis Oliphant]

On Jun 27, 2012, at 1:18 AM, Fernando Perez wrote:

> On Tue, Jun 26, 2012 at 11:02 PM, Travis Oliphant <travis at continuum.io> wrote:
>>  I just want to speak up for the people who are affected by API breakage who are not as vocal on this list.
> 
> Certainly!  And indeed I bet you that's a community underrepresented
> here: those of us who are on this list are likely to be up to speed on
> what's happening with the API and can therefore adjust to changes
> quickly, simply because we know they have occurred.  Random J. User
> who gets an upstream update and all of a sudden finds previously
> working code to break is unlikely to be active here and will be very,
> very unhappy

> If anything, the lesson is: for a project that's so deep in the
> dependency tree as numpy is, A{P,B}I stability is a paramount concern,
> with a cost that gets higher the more successful the project is.  This
> means AXIs should evolve only in backwards-compatible ways when at all
> possible, with backwards-compatibility being broken only in:

> 
> - clearly designated points that are agreed upon by as many as possible
> - with clear explanations of how old codes need to be adapted to the
> new interface to continue working
> - if at all possible with advance warnings, and even better, a system
> for 'future' loading.
> 


This is a good reminder.   I agree with your views here.   I've not been able to communicate very well my attitudes on this and I've been saddened at how eager some seem to pick apart my words to find problems with them.     My discussion about the ABI and API breakage should not be taken as an assertion that I don't recognize that ABI breakage is bad and has consequences.   I'm a little surprised that people assume I haven't been listening or paying attention or something.    But, I recognize that I don't always communicate clearly enough.   I do understand the consequences of ABI breakage.    I also understand the pain involved.    I have no plans to break the ABI.   

There is a certain group who is affected by ABI breakage and another group *more* affected by API breakage.     It feels like this list is particularly populated with people who feel pain by ABI breakage whereas the people who feel pain with API breakage are not as vocal, don' t track this list, etc.   But, their stories are just as compelling to me.   I understand the pain they feel as well when the NumPy API breaks.  It's just as important that we take them into consideration.    That's my only point.   

Right now, though,  arguing over the relative importance of ABI or API breakage is moot.    I was simply pointing out my perspective that I think a single ABI breakage in 1.5.0 would have been better than the API and use-case breakages that have been reported (I know these are only very weakly correlated so it's just an analogy).     If you disagree with me, that's fine.   Just understand that any frustration you feel about the thought of ABI breakage is the same as the frustration I feel about changes that cause working code to break for people.    I also understand that it's not quite the same thing because the phrase "changes that cause working code to break" is too strong.   Some code that "works"  has "work-arounds and hacks"  and assumptions about APIs.   In other word, it  is possible that some NumPy-dependent code out there works "accidentally".   

Of course, what is a "hack" or an "accidental" usage is not at all clear.   I can't define it.   It takes judgment to make a decision.   This judgment requires an awareness of the "intention of the original" code,  how big the user-base is of the group that is making the "hack".   How difficult it is to remedy the situation, etc.   These are hard problems.  I don't claim to understand how to solve all of them.   I don't claim that I won't make serious mistakes.    All I can do is offer my experience, my awareness of the code history (including the code history of Numeric and Numarray), and my interactions with many downstream users.    We need good judgment from as many NumPy developers as possible.   That judgment must be colored with empathy for as many users of NumPy as possible. 

Best, 

-Travis








> 
> Python in fact has the __future__ imports that help quite a bit for
> people to start adapting their codes.  How about creating a
> numpy.future module where new, non-backward-compatible APIs could go?
> That would give the adventurous a way to play with new features (hence
> getting them better tested) as well as an easier path for gradual
> migration to the new features by everyone.
> 
> This may have already been discussed before, forgive me if I'm
> repeating well-known material.

This is  a


> 
> Cheers,
> 
> f
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion