OK to upload patched 1.9.2 for Python 3.5?

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. Cheers, Matthew

On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <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. David
Cheers,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Hi, On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com> wrote:
On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <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. 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, 14 Sep 2015 01:32:13 -0700 Matthew Brett <matthew.brett@gmail.com> wrote:
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.
It's always bad to have two silent versions of a single release. People can never know up front which version they got, since it's not written anywhere. That's why the right policy is to bump the version number in some way (be it by incrementing it or adding a ".patchXXX" at the end). Regards Antoine.

On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com>
wrote:
On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <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

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 <robert.kern@gmail.com>:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com>
wrote:
On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <
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 http://mail.scipy.org/mailman/listinfo/numpy-discussion

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 <robert.kern@gmail.com <mailto:robert.kern@gmail.com>>:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <matthew.brett@gmail.com <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 3:47 AM, Julian Taylor <jtaylor.debian@googlemail.com> 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? Matthew

On Mon, Sep 14, 2015 at 9:42 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
On Mon, Sep 14, 2015 at 3:47 AM, Julian Taylor <jtaylor.debian@googlemail.com> 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

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 <robert.kern@gmail.com <mailto:robert.kern@gmail.com>>:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <matthew.brett@gmail.com <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> Christoph

Hi Christoph, On Mon, Sep 14, 2015 at 11:06 AM, Christoph Gohlke <cgohlke@uci.edu> 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 <robert.kern@gmail.com <mailto:robert.kern@gmail.com>>:
On Mon, Sep 14, 2015 at 9:32 AM, Matthew Brett <matthew.brett@gmail.com <mailto:matthew.brett@gmail.com>> wrote: > > Hi, > > On Mon, Sep 14, 2015 at 1:22 AM, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote: > > > > > > On Mon, Sep 14, 2015 at 9:18 AM, Matthew Brett <matthew.brett@gmail.com <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
participants (7)
-
Antoine Pitrou
-
Carl Kleffner
-
Christoph Gohlke
-
David Cournapeau
-
Julian Taylor
-
Matthew Brett
-
Robert Kern