[Numpy-discussion] Release of 1.0b5 this weekend
Travis Oliphant
oliphant.travis at ieee.org
Tue Aug 29 14:57:30 EDT 2006
Hi all,
Classes start for me next Tuesday, and I'm teaching a class for which I
will be using NumPy / SciPy extensively. I need to have a release of
these two (and hopefully matplotlib) that work with each other.
Therefore, I'm going to make a 1.0b5 release of NumPy over the weekend
(probably Monday), and also get a release of SciPy out as well. At that
point, I'll only be available for bug-fixes to 1.0. Therefore, the next
release after 1.0b5 I would like to be 1.0rc1 (release-candidate 1).
To facilitate that, after 1.0b5 there will be a feature-freeze (except
for in the compatibility modules and the alter_code scripts which can
still be modified to ease the transition burden).
The 1.0rc1 release of NumPy will be mid September I suspect.
Also, I recognize that the default-axis switch is a burden for those who
have already transitioned code to use NumPy (for those just starting out
it's not a big deal because of the compatibility layer). As a result,
I've added a module called fix_default_axis whose converttree method
will walk a hierarchy and change all .py files to fix the default axis
problem in those files. This can be done in one of two ways (depending
on the boolean argument import_change).
If import_change is False
a) Add and axis=<olddefault> keyword argument to any function whose
default changed in 1.0b2 or 1.0b3,
which does not already have the axis argument --- this method does
not distinguish where the
function came from and so can do the wrong thing with similarly
named functions from other modules
(.e.g. builtin sum and itertools.repeat).
If import_change is True
b) Change the location where the function is imported from numpy to
numpy.oldnumeric where the default axis
is the same as before. This approach looks for several flavors of
the import statement and alters the
import location for any function whose default axis argument
changed --- this can get confused if you
use from numpy import sum as mysum --- it will not replace that
usage of sum.
I used this script on the scipy tree in mode a) as a test (followed by a
manual replacement of all? incorrect substitutions). I hope it helps.
I know it's annoying to have such things change. But, it does make
NumPy much more consistent with respect to the default axis argument.
With a few exceptions (concatenate, diff, trapz, split, array_split),
the rule is that you need to specify the axis if there is more than 1
dimension or it will ravel the input.
-Travis
More information about the NumPy-Discussion
mailing list