Jarrod Millman wrote:

Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0

For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried). The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers.

The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December.

This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done)

A small summary of the issues: I don:t know the status on Mac OS X for python 2.6 - last time I tried, after having installed python 2.6, my installation was broken, and numpy had many trouble, but that may well be my own mistake. Since many developers are on Mac OS X, I guess any problem would be quickly fixed. On Windows: numpy.distutils should now build a working numpy with mingw, as long as the official binary for python 2.6 is built (I won:t go into the details, but python 2.6 lacks some useful build info for numpy to be reliably built with mingw for an arbitrary build - I am working on an upstream patch , but this is unlikely to be available before python 2.7/python 3k). Windows 64 is a PITA, because we can:t use any mingw or cygwin-based toolchain (cygwin only supports 32 bits, mingw is experimental for 64 bits, and not even officially a part of the mingw project AFAIK). It also looks like ATLAS cannot be built on 64 bits, too, since it requires cygwin on windows, and ATLAS configuration fails right at the beginning when I tried the 32 bits cywgin. Assuming I am the only one working on this, I don:t see much hope to see more than a simple numpy built with lapack-lite. This could be useful for people who use numpy for matplotlib, for example; not sure if it worths the trouble.

* Refactoring numpy.core math configuration (?? bump to 1.4 ??)

This has been committed already

* Improvements to build warnings (?? bump to 1.4 ??)

Some has been committed as well, but this has no consequence on distutils-based build (the warnings are only emitted with -W, which distutils does not use by default). David

Well, talking about support to 2.6: When using explicit outputs for some functions (eg, ma.max, ma.min...), a value that should be masked is transformed into np.nan when the explicit output is not a ma.MaskedArray. That worked great in 2.5, with np.nan automatically transformed when the explicit output had a int dtype. With 2.6, a ValueError is raised instead, as np.nan can no longer be casted to int. What should be the recommended behavior ? Raise a ValueError or some other exception, or silently replace np.nan by some value acceptable by int dtype (0, or something else) ? On Nov 24, 2008, at 8:57 AM, Francesc Alted wrote:

A Monday 24 November 2008, David Cournapeau escrigué:

...

Jarrod Millman wrote:

...

Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0

For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried).

The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers.

Not only newcomers, we all know people that likes to have the latest software in their machines even, as you said, 2.6 is not a big step forward in terms of new functionality. So +1 for having support for 2.6 ASAP.

Cheers,

-- Francesc Alted _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

David Cournapeau wrote:

Windows 64 is a PITA, ... I don:t see much hope to see more than a simple numpy built with lapack-lite. This could be useful for people who use numpy for matplotlib, for example; not sure if it worths the trouble.

I think there is a great deal of use for it beyond simple MPL use -- I hardly ever use the LAPACK stuff. Granted, I don't use Win64 either... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov