When to stop supporting Python 2.6?
Hi All, Thought I would raise the topic apropos this post <http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html> . There is not a great advantage to dropping 2.6, OTOH, 2.7 has more features (memoryview) and we could clean up the code a bit. Along the same lines, dropping support for Python 3.2 would allow more cleanup. In fact, I'd like to get to 3.4 as soon as possible, but don't know what would be a reasonable schedule. The Python 3 series might be easier to move forward on, as I think that Python 3 is just now starting to become the dominant version in some areas. Chuck <http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html>
I would be in favour of dropping 3.3, but not 2.6 until it becomes too cumbersome to support. As a data point, as of april, 2.6 was more downloaded than all python 3.X versions together when looking at pypi numbers: https://caremad.io/2015/04/a-year-of-pypi-downloads/ David On Thu, Dec 3, 2015 at 11:03 PM, Jeff Reback <jeffreback@gmail.com> wrote:
dropping 3.2: +-0 as it would remove some extra code in our broken py3 string handling but not much dropping 3.3: -1 doesn't gain us anything so far I know dropping 2.6: -1, I don't see not enough advantage the only issue I know of is an occasional set literal which gets caught by our test-suite immediately. Besides 2.6 is still the default in RHEL6. But if there is something larger which makes it worthwhile I don't know about I have no objections. On 04.12.2015 10:27, David Cournapeau wrote:
On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor <jtaylor.debian@googlemail.com
wrote:
My thought is that dropping 2.6 allows a more unified code base between Python 2 and Python3. In 2.7 we get - The syntax for set literals ({1,2,3} is a mutable set). - Dictionary and set comprehensions ({i: i*2 for i in range(3)}). - Multiple context managers in a single with <https://docs.python.org/3/reference/compound_stmts.html#with> statement. - A new version of the io <https://docs.python.org/3/library/io.html#module-io> library, rewritten in C for performance. - The ordered-dictionary type described in *PEP 372: Adding an Ordered Dictionary to collections* <https://docs.python.org/3/whatsnew/2.7.html#pep-0372>. - The new "," format specifier described in *PEP 378: Format Specifier for Thousands Separator* <https://docs.python.org/3/whatsnew/2.7.html#pep-0378>. - The memoryview <https://docs.python.org/3/library/stdtypes.html#memoryview> object. - A small subset of the importlib <https://docs.python.org/3/library/importlib.html#module-importlib> module, described below <https://docs.python.org/3/whatsnew/2.7.html#importlib-section>. - The repr() <https://docs.python.org/3/library/functions.html#repr> of a float x is shorter in many cases: it’s now based on the shortest decimal string that’s guaranteed to round back to x. As in previous versions of Python, it’s guaranteed that float(repr(x)) recovers x. - Float-to-string and string-to-float conversions are correctly rounded. The round() <https://docs.python.org/3/library/functions.html#round> function is also now correctly rounded. - The PyCapsule <https://docs.python.org/3/c-api/capsule.html#c.PyCapsule> type, used to provide a C API for extension modules. - The PyLong_AsLongAndOverflow() <https://docs.python.org/3/c-api/long.html#c.PyLong_AsLongAndOverflow> C API function. In particular, memoryview and PyCapsule are available. Moving to Python 3.3 as a minimum provides unicode literals. Python 3.4 strikes me as the end of the Python 3 beginning, with future Python development taking off from there. <snip> Chuck
I'd suggest that anything that unifies the codebase and reduces complexity and special cases will not only help current developers, but also lower the bar for potential new developers as well. The importance of streamlining and reducing the maintenance burden in long-running projects cannot be overstated, in my opinion. I'd also suggest that Numpy is in a unique position proactively encourage people to use more reasonable versions of python, and for those that can't or won't (yet) it's not like older versions of Numpy will disappear. A brief search seems to affirm my feeling that "2.7 + 3.3/3.4" support is becoming fairly standard among a wide range of OSS python projects. Regarding RHEL6 comment above, even Nick Coghlan suggests that is not a compelling motivation: http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html """ While it's entirely admirable that many upstream developers are generous enough to help their end users work around this inertia, in the long run doing so is detrimental for everyone concerned, as long term sustaining engineering for old releases is genuinely demotivating for upstream developers (it's a good job, but a lousy way to spend your free time) and for end users, working around institutional inertia this way reduces the pressure to actually get the situation addressed properly. """ Bryan
On Fri, Dec 4, 2015 at 9:29 AM, Bryan Van de Ven <bryanv@continuum.io> wrote:
As a strawman proposal, how about dropping moving to 2.7 and 3.4 minimum supported version next fall, say around numpy 1.12 or 1.13 depending on how the releases go. I would like to here from the scipy folks first. Chuck
Charles R Harris <charlesr.harris@gmail.com> wrote:
Personally I would be in favor of this, because 2.7 and 3.4 are the minimum versions anyone should consider to use. However, for SciPy which heavily depends on Python code, the real improvement will be when we can bump the minimum Python version to 3.5 and write x @ y instead of dot(x,y). I am not sure of bumping the minimum version to 3.4 before that is worth it or not. But certainly dropping 2.6 might be a good thing already now, so we can start to use bytes, bytearray, memoryview, etc. Sturla
drop 2.6 I still don't understand why folks insist that they need to run a (very)) old python on an old OS, but need the latest and greatest numpy. Chuck's list was pretty long and compelling. -CHB On Mon, Dec 7, 2015 at 1:38 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
-- 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
On Wed, Dec 9, 2015 at 12:01 AM, Chris Barker <chris.barker@noaa.gov> wrote:
+1 for dropping Python 2.6, 3.2 and 3.3 after branching 1.11.x. We're already behind other projects like ipython, pandas and matplotlib as usual, so there really isn't much point in being the only project (together with scipy) of the core stack to keep on supporting more or less obsolete Python versions. Ralf
On Tue, Dec 8, 2015 at 6:51 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Looks like the decision has been made--but just to add another data point on this, the Astropy project decided to keep Python 2.6 support for the upcoming release (v1.1) but adds a deprecation warning, and support will be dropped altogether in the next release (v1.2) out sometime next year. The critical deciding factor was the (informal, non-scientific) poll of (mostly) astrophysics Python users [1] which showed just 2% of users on Python 2.6. Anecdotally, I think even in the ~half year since then there has been even more movement to scientific Python distributions, and so I would not be surprised if that number has already dropped to <1% if the exact same people were surveyed. Hard to say though. Erik [1] http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/
On 12/09/2015 12:10 AM, Ralf Gommers wrote:
I don't see how that is a relevant point. NumPy is the lowest component of the stack, we have to be the last to drop support for Python 2.6. And we aren't yet the last even when only looking at the high profile components. Astropy still supports 2.6 for another release. Though by the time 1.11 comes out we might be so I'm ok with dropping it after that even when I'm not convinced we gain anything significant from doing so.
On Thu, Dec 10, 2015 at 4:20 AM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:
Purely from a user-perspective, I don't understand why the numpy team would want to continue support Python <= 2.6 and <= 3.3. The old versions of numpy aren't going anywhere, so they can still be used if, for example, you're stuck on a 6-yr old license of ArcGIS, and therefore stuck on Python 2.6 I started using Python with version 2.4 or 2.5 and there was zero discussion about supporting old Python 1.X versions then. I know those situations are aren't directly comparable, but when can we let the past go? -paul
Another numpy user here. At work we have the old Scientific Linux 6, which has Python 2.6 and an old Numpy version. For most of my work I want and often need a newer Python and Numpy, which I can install in $HOME with conda. For the old system Python 2.6 the sysadmin would never install Numpy 1.12, even if it was supported. The whole idea is to leave it alone to make sure it’s stable. I don’t understand the use case. Is there anyone that really needs to install the future Numpy 1.12 into very old Python 2.6 installs? Christoph
On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau <cournape@gmail.com> wrote:
I'm not sure what's up with those numbers though -- they're *really* unrepresentative of what we see for numpy otherwise. E.g. they show 3.X usage as ~5%, but for numpy, 3.x usage has risen past 25%. (Source: 'vanity numpy', looking at OS X wheels b/c they're per-version and unpolluted by CI download spam. Unfortunately this doesn't provide numbers for 2.6 b/c we don't ship 2.6 binaries.) For all we know all those 2.6 downloads are travis builds testing projects on 2.6 to make sure they keep working because there are so many 2.6 downloads on pypi :-). Which isn't an argument for dropping 2.6 either, I just wouldn't put much weight on that blog post either way... (Supporting 2.6 in numpy hasn't been a big deal so far AFAICR, but I'd be in favor of dropping it as soon as supporting it becomes even a minor hassle.) -n -- Nathaniel J. Smith -- http://vorpus.org
On Fri, Dec 4, 2015 at 11:06 AM, Nathaniel Smith <njs@pobox.com> wrote:
I agree pypi is only one data point. The proportion is also package dependent (e.g. django had higher proportion of python 3.X). It is just that having multiple data points is often more useful than guesses David
On Fri, Dec 4, 2015 at 6:13 AM, David Cournapeau <cournape@gmail.com> wrote:
I agree that PyPI numbers appear to be dominated by something other than user downloads. As a concrete indication of usage statistics, Tom Robitaille did a survey earlier this year which showed that about 2% of respondents were running Python 2.6: http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/ Astropy is planning to drop support for Python 2.6 in the next major release (1.2) which is scheduled for about 6 months from now. - Tom
I would be in favour of dropping 3.3, but not 2.6 until it becomes too cumbersome to support. As a data point, as of april, 2.6 was more downloaded than all python 3.X versions together when looking at pypi numbers: https://caremad.io/2015/04/a-year-of-pypi-downloads/ David On Thu, Dec 3, 2015 at 11:03 PM, Jeff Reback <jeffreback@gmail.com> wrote:
dropping 3.2: +-0 as it would remove some extra code in our broken py3 string handling but not much dropping 3.3: -1 doesn't gain us anything so far I know dropping 2.6: -1, I don't see not enough advantage the only issue I know of is an occasional set literal which gets caught by our test-suite immediately. Besides 2.6 is still the default in RHEL6. But if there is something larger which makes it worthwhile I don't know about I have no objections. On 04.12.2015 10:27, David Cournapeau wrote:
On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor <jtaylor.debian@googlemail.com
wrote:
My thought is that dropping 2.6 allows a more unified code base between Python 2 and Python3. In 2.7 we get - The syntax for set literals ({1,2,3} is a mutable set). - Dictionary and set comprehensions ({i: i*2 for i in range(3)}). - Multiple context managers in a single with <https://docs.python.org/3/reference/compound_stmts.html#with> statement. - A new version of the io <https://docs.python.org/3/library/io.html#module-io> library, rewritten in C for performance. - The ordered-dictionary type described in *PEP 372: Adding an Ordered Dictionary to collections* <https://docs.python.org/3/whatsnew/2.7.html#pep-0372>. - The new "," format specifier described in *PEP 378: Format Specifier for Thousands Separator* <https://docs.python.org/3/whatsnew/2.7.html#pep-0378>. - The memoryview <https://docs.python.org/3/library/stdtypes.html#memoryview> object. - A small subset of the importlib <https://docs.python.org/3/library/importlib.html#module-importlib> module, described below <https://docs.python.org/3/whatsnew/2.7.html#importlib-section>. - The repr() <https://docs.python.org/3/library/functions.html#repr> of a float x is shorter in many cases: it’s now based on the shortest decimal string that’s guaranteed to round back to x. As in previous versions of Python, it’s guaranteed that float(repr(x)) recovers x. - Float-to-string and string-to-float conversions are correctly rounded. The round() <https://docs.python.org/3/library/functions.html#round> function is also now correctly rounded. - The PyCapsule <https://docs.python.org/3/c-api/capsule.html#c.PyCapsule> type, used to provide a C API for extension modules. - The PyLong_AsLongAndOverflow() <https://docs.python.org/3/c-api/long.html#c.PyLong_AsLongAndOverflow> C API function. In particular, memoryview and PyCapsule are available. Moving to Python 3.3 as a minimum provides unicode literals. Python 3.4 strikes me as the end of the Python 3 beginning, with future Python development taking off from there. <snip> Chuck
I'd suggest that anything that unifies the codebase and reduces complexity and special cases will not only help current developers, but also lower the bar for potential new developers as well. The importance of streamlining and reducing the maintenance burden in long-running projects cannot be overstated, in my opinion. I'd also suggest that Numpy is in a unique position proactively encourage people to use more reasonable versions of python, and for those that can't or won't (yet) it's not like older versions of Numpy will disappear. A brief search seems to affirm my feeling that "2.7 + 3.3/3.4" support is becoming fairly standard among a wide range of OSS python projects. Regarding RHEL6 comment above, even Nick Coghlan suggests that is not a compelling motivation: http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html """ While it's entirely admirable that many upstream developers are generous enough to help their end users work around this inertia, in the long run doing so is detrimental for everyone concerned, as long term sustaining engineering for old releases is genuinely demotivating for upstream developers (it's a good job, but a lousy way to spend your free time) and for end users, working around institutional inertia this way reduces the pressure to actually get the situation addressed properly. """ Bryan
On Fri, Dec 4, 2015 at 9:29 AM, Bryan Van de Ven <bryanv@continuum.io> wrote:
As a strawman proposal, how about dropping moving to 2.7 and 3.4 minimum supported version next fall, say around numpy 1.12 or 1.13 depending on how the releases go. I would like to here from the scipy folks first. Chuck
Charles R Harris <charlesr.harris@gmail.com> wrote:
Personally I would be in favor of this, because 2.7 and 3.4 are the minimum versions anyone should consider to use. However, for SciPy which heavily depends on Python code, the real improvement will be when we can bump the minimum Python version to 3.5 and write x @ y instead of dot(x,y). I am not sure of bumping the minimum version to 3.4 before that is worth it or not. But certainly dropping 2.6 might be a good thing already now, so we can start to use bytes, bytearray, memoryview, etc. Sturla
drop 2.6 I still don't understand why folks insist that they need to run a (very)) old python on an old OS, but need the latest and greatest numpy. Chuck's list was pretty long and compelling. -CHB On Mon, Dec 7, 2015 at 1:38 AM, Sturla Molden <sturla.molden@gmail.com> wrote:
-- 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
On Wed, Dec 9, 2015 at 12:01 AM, Chris Barker <chris.barker@noaa.gov> wrote:
+1 for dropping Python 2.6, 3.2 and 3.3 after branching 1.11.x. We're already behind other projects like ipython, pandas and matplotlib as usual, so there really isn't much point in being the only project (together with scipy) of the core stack to keep on supporting more or less obsolete Python versions. Ralf
On Tue, Dec 8, 2015 at 6:51 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Looks like the decision has been made--but just to add another data point on this, the Astropy project decided to keep Python 2.6 support for the upcoming release (v1.1) but adds a deprecation warning, and support will be dropped altogether in the next release (v1.2) out sometime next year. The critical deciding factor was the (informal, non-scientific) poll of (mostly) astrophysics Python users [1] which showed just 2% of users on Python 2.6. Anecdotally, I think even in the ~half year since then there has been even more movement to scientific Python distributions, and so I would not be surprised if that number has already dropped to <1% if the exact same people were surveyed. Hard to say though. Erik [1] http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/
On 12/09/2015 12:10 AM, Ralf Gommers wrote:
I don't see how that is a relevant point. NumPy is the lowest component of the stack, we have to be the last to drop support for Python 2.6. And we aren't yet the last even when only looking at the high profile components. Astropy still supports 2.6 for another release. Though by the time 1.11 comes out we might be so I'm ok with dropping it after that even when I'm not convinced we gain anything significant from doing so.
On Thu, Dec 10, 2015 at 4:20 AM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:
Purely from a user-perspective, I don't understand why the numpy team would want to continue support Python <= 2.6 and <= 3.3. The old versions of numpy aren't going anywhere, so they can still be used if, for example, you're stuck on a 6-yr old license of ArcGIS, and therefore stuck on Python 2.6 I started using Python with version 2.4 or 2.5 and there was zero discussion about supporting old Python 1.X versions then. I know those situations are aren't directly comparable, but when can we let the past go? -paul
Another numpy user here. At work we have the old Scientific Linux 6, which has Python 2.6 and an old Numpy version. For most of my work I want and often need a newer Python and Numpy, which I can install in $HOME with conda. For the old system Python 2.6 the sysadmin would never install Numpy 1.12, even if it was supported. The whole idea is to leave it alone to make sure it’s stable. I don’t understand the use case. Is there anyone that really needs to install the future Numpy 1.12 into very old Python 2.6 installs? Christoph
On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau <cournape@gmail.com> wrote:
I'm not sure what's up with those numbers though -- they're *really* unrepresentative of what we see for numpy otherwise. E.g. they show 3.X usage as ~5%, but for numpy, 3.x usage has risen past 25%. (Source: 'vanity numpy', looking at OS X wheels b/c they're per-version and unpolluted by CI download spam. Unfortunately this doesn't provide numbers for 2.6 b/c we don't ship 2.6 binaries.) For all we know all those 2.6 downloads are travis builds testing projects on 2.6 to make sure they keep working because there are so many 2.6 downloads on pypi :-). Which isn't an argument for dropping 2.6 either, I just wouldn't put much weight on that blog post either way... (Supporting 2.6 in numpy hasn't been a big deal so far AFAICR, but I'd be in favor of dropping it as soon as supporting it becomes even a minor hassle.) -n -- Nathaniel J. Smith -- http://vorpus.org
On Fri, Dec 4, 2015 at 11:06 AM, Nathaniel Smith <njs@pobox.com> wrote:
I agree pypi is only one data point. The proportion is also package dependent (e.g. django had higher proportion of python 3.X). It is just that having multiple data points is often more useful than guesses David
On Fri, Dec 4, 2015 at 6:13 AM, David Cournapeau <cournape@gmail.com> wrote:
I agree that PyPI numbers appear to be dominated by something other than user downloads. As a concrete indication of usage statistics, Tom Robitaille did a survey earlier this year which showed that about 2% of respondents were running Python 2.6: http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/ Astropy is planning to drop support for Python 2.6 in the next major release (1.2) which is scheduled for about 6 months from now. - Tom
participants (14)
-
Aldcroft, Thomas -
Bryan Van de Ven -
Charles R Harris -
Chris Barker -
Christoph Deil -
David Cournapeau -
Eric Firing -
Erik Bray -
Jeff Reback -
Julian Taylor -
Nathaniel Smith -
Paul Hobson -
Ralf Gommers -
Sturla Molden