[Numpy-discussion] Release of 1.0b5 this weekend

Travis Oliphant oliphant.travis at ieee.org
Tue Aug 29 13:57:30 CDT 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.


More information about the Numpy-discussion mailing list