[Numpy-discussion] future directions

Joe Harrington jh@physics.ucf....
Fri Aug 28 10:26:14 CDT 2009


> ...numpy clean-up...
> ...cruft...
> ...API breakage...
> ...etc....

At the risk of starting a flame war, the cleanest way out of the
legacy API trap is some level of fork, with the old code maintained
for some years while new uses (new users and new code by old users)
get done in the new package, which is named differently.  The reader
will note that "fork" is a four-letter word, particularly in this
community.

However, there are two natural forklets coming up.

The first is Python 3.0, which will necessitate some API changes.  A
numpy 2.0 that used Python 3.0 could have significant API breaks and
might include a cleanup.  Yet, there would still be resistance to that
level of API breakage and I can't say I'd be on the breaking side of
that debate.  In any event, a Python 2.x branch would need to be
maintained unless the Python 3.x branch was completely backward
compatible, which I am not sure it will be.

I won't claim to be Yoda, but there is another.

There seems to be consensus that something like ndarray go into the
Python language.  There is also an increasing amount of talk about
putting numpy itself into the core "eventually", and increasing
agreement from the mainstream Python community, too.  The resistance
from that side seems to be 1) we (the Python community) don't have the
numerical expertise to maintain it, 2) it's not clean enough, and
sometimes 3) it's too big.

So, it may be worthwhile making a cleaned-up successor to numpy, with
a different name, that is intended for inclusion in Python.  That
would answer objection 2.  I think that we have demonstrated the
strength of this community sufficiently to say that we'll maintain
that part of Python as if it were our own, because it would be, and
that such participation would be sufficient.  The size problem, if
there is one, gets helped a lot by removal of all the cruft.  Anything
useful from the original package that didn't go into Python would go
into the scipy package.  We'd maintain the old numpy for a few years
at least.

To do any of these right, I think we need to establish a more formal
mechanism for proposing, discussing, and deciding API issues, and then
stick to it like glue.  Failing that, we should not even attempt a
cleanup, as it will just be one more dirty fork.  Following the full
PEP procedure would be appropriate for developing a Python language
candidate package.

--jh--


More information about the NumPy-Discussion mailing list