Hi, On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau wrote:

On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett wrote:

...

Hi,

I'm just building numpy 1.9.2 for Python 3.5 (just released).

In order to get the tests to pass on Python 3.5, I need to cherry pick commit 7d6aa8c onto the 1.9.2 tag position.

Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.

Why not releasing this as 1.9.3 ? It does not need to be a full release (with binaries and all), but having multiple sources for a given tag is confusing.

Generally OK with me, but it's quite a bit of extra work for very little gain. We'd have to tag, release a source tarball and OSX wheels, at least. The patch being cherry-picked is just deleting some legacy monkey-patching of gzip: https://github.com/numpy/numpy/commit/7d6aa8c721d5274ac57d0c87685d472cb1fd79... and it's difficult for me to imagine this could cause a problem with source differences. Cheers, Matthew

On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett wrote:

Hi,

On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau

wrote:

...

On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett wrote:

...

Hi,

I'm just building numpy 1.9.2 for Python 3.5 (just released).

In order to get the tests to pass on Python 3.5, I need to cherry pick commit 7d6aa8c onto the 1.9.2 tag position.

Does anyone object to me uploading a wheel built from this patched version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get the ball rolling for Python 3.5 binary wheels.

Why not releasing this as 1.9.3 ? It does not need to be a full release (with binaries and all), but having multiple sources for a given tag is confusing.

Generally OK with me, but it's quite a bit of extra work for very little gain. We'd have to tag, release a source tarball and OSX wheels, at least.

I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch. -- Robert Kern

as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed. On 09/14/2015 11:21 AM, Carl Kleffner wrote:

I would like to add patches for the mingwpy windows build as well. There is no Python-3.5 build so far.

Carlkl

2015-09-14 10:46 GMT+02:00 Robert Kern mailto:robert.kern@gmail.com>:

On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett mailto:matthew.brett@gmail.com> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau mailto:cournape@gmail.com> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett mailto:matthew.brett@gmail.com> > > wrote: > >> > >> Hi, > >> > >> I'm just building numpy 1.9.2 for Python 3.5 (just released). > >> > >> In order to get the tests to pass on Python 3.5, I need to cherry pick > >> commit 7d6aa8c onto the 1.9.2 tag position. > >> > >> Does anyone object to me uploading a wheel built from this patched > >> version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get > >> the ball rolling for Python 3.5 binary wheels. > > > > > > Why not releasing this as 1.9.3 ? It does not need to be a full release > > (with binaries and all), but having multiple sources for a given tag is > > confusing. > > Generally OK with me, but it's quite a bit of extra work for very > little gain. We'd have to tag, release a source tarball and OSX > wheels, at least.

I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch.

-- Robert Kern

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Mon, Sep 14, 2015 at 9:42 AM, Matthew Brett wrote:

On Mon, Sep 14, 2015 at 3:47 AM, Julian Taylor wrote:

...

as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed.

OK - fair enough - it would be good to do this soon as possible, as Python 3.5 is currently the default download from the Python.org site (rather than Python 2.7) and most other binary installers depend on numpy. Is there anything I can do to help?

For example, how about a rush-out 1.9.3 release with just the gzip patch, and a very-soon release with further patches? Matthew

Hi Christoph, On Mon, Sep 14, 2015 at 11:06 AM, Christoph Gohlke wrote:

On 9/14/2015 3:47 AM, Julian Taylor wrote:

...

as due to the many incompatiblities in 1.10 many will likely not be able to update anytime soon, so I think putting out another 1.9.3 bugfix release would be a good idea. I can probably do the release management for it, though I haven't been keeping up with bugfixes recently so, please comment on important issues you would want fixed. The np.where upcast regression and np.nanmedian issues come to my mind as should be fixed.

On 09/14/2015 11:21 AM, Carl Kleffner wrote:

...

I would like to add patches for the mingwpy windows build as well. There is no Python-3.5 build so far.

Carlkl

2015-09-14 10:46 GMT+02:00 Robert Kern mailto:robert.kern@gmail.com>:

On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett mailto:matthew.brett@gmail.com> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau mailto:cournape@gmail.com> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett mailto:matthew.brett@gmail.com> > > wrote: > >> > >> Hi, > >> > >> I'm just building numpy 1.9.2 for Python 3.5 (just released). > >> > >> In order to get the tests to pass on Python 3.5, I need to cherry pick > >> commit 7d6aa8c onto the 1.9.2 tag position. > >> > >> Does anyone object to me uploading a wheel built from this patched > >> version to pypi as 1.9.2 for Python 3.5 on OSX? It would help to get > >> the ball rolling for Python 3.5 binary wheels. > > > > > > Why not releasing this as 1.9.3 ? It does not need to be a full release > > (with binaries and all), but having multiple sources for a given tag is > > confusing. > > Generally OK with me, but it's quite a bit of extra work for very > little gain. We'd have to tag, release a source tarball and OSX > wheels, at least.

I think it's highly desirable that we also have a *source* release that builds on Python 3.5, irrespective of whether or not we have binary wheels for a couple of platforms up for Python 3.5. So I would encourage a quick 1.9.3 release that incorporates this patch.

-- Robert Kern

Support for Visual Studio 2015 and Intel Fortran 16 for Python 3.5 on Windows would also be nice.

I am using:

DEV: Replace deprecated options for ifort https://github.com/numpy/numpy/pull/5555

remove /GL for vs2015 in check_long_double_representation https://github.com/numpy/numpy/pull/6096

Enable Visual Studio 2015 C99 features https://github.com/numpy/numpy/pull/6141

BLD: revert C99 complex for msvc14 https://github.com/numpy/numpy/pull/6171

Would you mind making a branch for these, preferably starting from my current branch: git://github.com/matthew-brett/numpy.git branch prepare-1.9.3 ? I had a quick go, but the merge conflicts needed more understanding than I had of the Windows build. Thanks a lot, Matthew