Repository navigation
Bump numpy minimal version to 1.7.0? #7396
Description
I would like to propose (purely for convenience reasons) to bump the minimal numpy version to 1.7.0. There are a couple of hacks left to support numpy 1.6 (category.py, tests/test_category.py, cbook.py (putmask vs copyto), possibly(?) colors.py), and 1.7 also introduced the ability to pass a tuple as the axis kwarg to reducing ufuncs.
numpy 1.7.0 was released in Feb. 2013 (3y 9m ago). As a comparison, the minimal version of numpy was bumped to 1.6.0 in Jul. 2014 (#3229), 3y 2m after its release (May 2011) (and was effective with the release of mpl1.4.0 in Aug. 2014).
Edit: I misread the release notes of 1.7.0 -- turns out that what it added was the ability to pass multiple axes as a tuple to reducing ufuncs; passing a single axis was supported since long ago (and that was one of my bigger reasons). So the issue is less pressing on my side at least.
Activity
tacaswell commentedon Nov 3, 2016
I am 👍 , but it would be very easy to talk me out of it.
story645 commentedon Nov 3, 2016
I am 👍*100, mostly 'cause it's my code that's a mess 'cause of this.
WeatherGod commentedon Nov 3, 2016
I am assuming that this would be for v2.1? I am -1 for doing so for v2.0,
but can be convinced to do so for v2.1.
On Thu, Nov 3, 2016 at 9:29 AM, hannah [email protected] wrote:
NelleV commentedon Nov 3, 2016
That seems like a good idea.
NelleV commentedon Nov 3, 2016
(For scikit-learn the criteria is to support at least what is in the latest Ubuntu LTS, which is currently 1.8).
QuLogic commentedon Nov 3, 2016
Another (rather minor) plus is that we can finally enable those
#defines that stop NumPy headers from warning about stuff that changed in the 1.7.0 C bindings. I might have a patch for that already, somewhere...QuLogic commentedon Nov 3, 2016
Oh, actually turns out that macro is already enabled and since there are no errors, we don't use any of the deprecated API. One less explicit benefit I guess.
efiring commentedon Nov 3, 2016
I'm happy with seeing this change for 2.1.
efiring commentedon Nov 17, 2016
What is the big argument for not bumping it to 1.7 now? Is this conservatism doing us and our users any big favor? Isn't an new major version number a good place to make such a change?
efiring commentedon Nov 17, 2016
Scipy 0.18.0: "This release requires Python 2.7 or 3.4-3.5 and NumPy 1.7.1 or greater." I don't see any reason why we should lag scipy in this respect.
dopplershift commentedon Nov 17, 2016
The argument against, and I'm not sure where I stand on it personally, is that bumping the numpy version gives users stuck on the old version no upgrade path for the new styles; therefore when they move, they have an even bigger change to deal with.
efiring commentedon Nov 17, 2016
And I think the counter-argument is that anyone who can install an up-to-date matplotlib can just as easily install an up-to-date numpy.
Are there really any users out there for which this is not true?
dopplershift commentedon Nov 17, 2016
Bumping numpy leads to needing to rebuild packages which are linked to numpy's C-API. Matplotlib is usually a leaf in the graph (numpy's not), so bumping matplotlib doesn't require rebuilding other stuff.
efiring commentedon Nov 17, 2016
Two more data points: Ubuntu 14.04LTS has numpy 1.8.1. RHEL 7 has numpy 1.7.1.
efiring commentedon Nov 17, 2016
My argument stands: yes, it is possible that someone, somewhere, will be bent out of shape by not being able to install 2.x natively (that is, without Anaconda or similar) without additional updates, and will be left stuck with our old style. They will have to keep using 1.5.3, or whatever earlier version they are already using--and have probably been using happily for a long time, style and all. (On the plus side, they will not be tripping over whatever undetected bugs and glitches we have introduced with the style overhaul--and I am sure there will be some.) But I think that such cases of user pain will be so rare, if they occur at all, that they should not block us.
WeatherGod commentedon Nov 17, 2016
My argument against bumping it for 2.0 is that the promise has been that
2.0 would be (mostly) just style changes. There is no pressing need to bump
it for 2.0, and numpy 1.6 was the minimum requirement for our v1.5. So
someone being told that the upgrade to 2.0 is "just style changes" would be
quite confused when he has to recompile everything because numpy got
upgraded unexpectedly.
On Thu, Nov 17, 2016 at 5:24 PM, Eric Firing [email protected]
wrote:
efiring commentedon Nov 17, 2016
On 2016/11/17 12:35 PM, Benjamin Root wrote:
Weak argument. Note the "mostly", and the fact that until 2.0 is
released we have plenty of wiggle-room. Do you really think the sort of
person who is installing a hot-off-the-press matplotlib, natively,
without something like Anaconda, is going to be "quite confused" if we
advertise the release as requiring 1.7.1, when we had said it would be
mostly just style changes? And this person has to be among the small
population of people still using numpy 1.6.
Right now, for #7476, we need 1.7.1; or we need to make our own version
of isclose, which we would then remove in master. #7476, or something
like it, is actually well beyond a style change, but is critical to
making the style change work.
2.0 is the right place to make the change. It will make it easier to
progress towards 2.1, backporting bug-fixes to 2.x.
NelleV commentedon Nov 17, 2016
I am fine with bumping the requirement for numpy to 1.7 for 2.0.
dopplershift commentedon Nov 17, 2016
To be clear @efiring, that's the first time a concrete benefit of moving has actually been mentioned--you may want to consider leading with that next time. Last word before that was "nevermind, I don't really need it" from @anntzer.
efiring commentedon Nov 18, 2016
@dopplershift, agreed, I failed to say why I suddenly thought it mattered.
But there is a more general argument for this sort of change. The larger the range of numpy versions we support, the larger the potential for running into problems with numpy bugs and behavior changes. And the greater the delay between the time a new feature is introduced and the time when we can take advantage of it. In other words, there is a real benefit to matplotlib development in moving up the minimum version, and a real cost in delaying the move.
dopplershift commentedon Nov 18, 2016
Agree completely--so long as we do it with an eye to the real benefits we'll see (i.e. new features) and acknowledge the cost to our users (such as those who have to have a sysadmin build their own stack on, e.g. solaris)
tacaswell commentedon Nov 18, 2016
I would come down on the side of bumping the minimum version over vendoring a version of
isclosein 2.0 but then not on master.dopplershift commentedon Nov 18, 2016
I'm 👍 as well now.
WeatherGod commentedon Nov 18, 2016
Ok, now that there is a concrete reason for bumping the minimum version
after we promised we wouldn't for 2.0, I will agree to that.
As for the general argument about what versions of numpy to support, I have
no problem with bumping up the minimum version -- but you must show me
evidence of a benefit and that benefit should outweigh the costs. Right
now, I am stuck on numpy 1.9 at work because version 1.10 and 1.11 have
each had separate show-stopper bugs for my projects. I am right now
evaluating the 1.12 beta, but it seems that it might also have another
show-stopper bug (trying to trace down the fault right now). The point is
that on production systems that have had its results verified, we may have
very esoteric reasons for not upgrading certain parts of the stack for
awhile.
(Yes, I know, using a CI would mitigate this significantly...)
On Thu, Nov 17, 2016 at 10:29 PM, Ryan May [email protected] wrote:
tacaswell commentedon Nov 18, 2016
Closed by #7483