On Tue, Jun 26, 2012 at 11:02 PM, Travis Oliphant <tra...@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.
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.
Cheers,
f
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
