On 01/25/2011 10:28 PM, Mark Wiebe wrote:
On Tue, Jan 25, 2011 at 5:18 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:


On Tue, Jan 25, 2011 at 1:13 PM, Travis Oliphant <oliphant@enthought.com> wrote:

On Jan 25, 2011, at 10:42 AM, Charles R Harris wrote:

> Hi All,
>
> Just thought it was time to start discussing a release schedule for numpy 2.0 so we have something to aim at. I'm thinking sometime in the period April-June might be appropriate. There is a lot coming with the next release: the Enthought's numpy refactoring, Mark's float16 and iterator work, and support for IronPython. How do things look to the folks involved in those projects?

My suggestion is to do a 1.6 relatively soon, as the current trunk feels pretty stable to me, and it would be nice to release the features without having to go through the whole merging process.
 

I would target June / July at this point ;-)    I know I deserve a "I told you so" from Chuck --- I will take it.


How much remains to get done?

My changes probably make merging the refactor more challenging too.
 
 
There is a bit of work that Mark is doing that would be good to include, also some modifications to the re-factoring that will support better small array performance.


Not everything needs to go into first release as long as the following releases are backward compatible. So the ABI needs it's final form as soon as possible. Is it still in flux?

I would suggest it is - there are a number of things I think could be improved in it, and it would be nice to bake in the underlying support features to make lazy/deferred evaluation of array expressions possible.
 
It may make sense for a NumPy 1.6 to come out in March / April in the interim.


Pulling out the changes to attain backward compatibility isn't getting any easier. I'd rather shoot for 2.0 in June. What can the rest of us do to help move things along?

I took a shot at fixing the ABI compatibility, and if PyArray_ArrFunc was the main issue, then that might be done.  An ABI compatible 1.6 with the datetime and half types should be doable, just some extensions might get confused if they encounter arrays made with the new data types.

-Mark

I do understand that it may take time for the 'dust to settle' but there is the opportunity to implement aspects that may require 'significant' notification or least start the process for any appropriate changes.

So, would it be possible to start developing some strategic plan of the changes that will occur?

The type of things I think are in terms of:

1) Notifying/warning users of the API changes that will occur. I agree with Chuck that other 'eyes' need to see it.

2) Add any desired depreciation warnings but I do not know of any. Perhaps the files in numpy/oldnumeric and numpy/numarray - if these are still important then these should have a better home since both have not had a release since mid 2006.

3) Changes or reorganization of the namespace.
My personal one is my ticket 1051 (Renaming and removing NaN and related IEEE754 special cases):
http://projects.scipy.org/numpy/ticket/1051
Hopefully some of it will be applied.

4) Changes in functions.
Examples:
Ticket 1262 (genfromtxt: dtype should be None by default)
http://projects.scipy.org/numpy/ticket/1262

Tickets 465 and 518 related to the accumulator dtype argument issues because this topic keeps appearing on the list.
http://projects.scipy.org/numpy/ticket/518
http://projects.scipy.org/numpy/ticket/465
For example, perhaps changing the default arguments of mean in numpy/core/fromnumeric.py as that allows the old behavior to remain by changing the dtype argument:
Change:
def mean(a, axis=None, dtype=None, out=None):
To:
def mean(a, axis=None, dtype=float, out=None):

5) Adding any enhancement patches like median of Ticket 1213
http://projects.scipy.org/numpy/ticket/1213

Bruce