[Numpy-discussion] When to stop supporting Python 2.6?

[Charles R Harris]

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>

[Eric Firing]

Post by Charles R Harris
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>

Chuck,

I would support dropping the old versions now. As a related data point,
matplotlib is testing master on 2.7, 3.4, and 3.5--no more 2.6 and 3.3.

Eric

[Bryan Van de Ven]

Post by Eric Firing
Chuck,
I would support dropping the old versions now. As a related data point, matplotlib is testing master on 2.7, 3.4, and 3.5--no more 2.6 and 3.3.

Ditto for Bokeh.

[Jeff Reback]

pandas is going to drop
2.6 and 3.3 next release at end of Jan

(3.2 dropped in 0.17, in October)



I can be reached on my cell 917-971-6387

Post by Bryan Van de Ven

Post by Eric Firing
Chuck,
I would support dropping the old versions now. As a related data point, matplotlib is testing master on 2.7, 3.4, and 3.5--no more 2.6 and 3.3.

Ditto for Bokeh.
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[David Cournapeau]

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

Post by Jeff Reback
pandas is going to drop
2.6 and 3.3 next release at end of Jan
(3.2 dropped in 0.17, in October)
I can be reached on my cell 917-971-6387

Post by Bryan Van de Ven

Post by Eric Firing
Chuck,
I would support dropping the old versions now. As a related data

point, matplotlib is testing master on 2.7, 3.4, and 3.5--no more 2.6 and
3.3.

Post by Bryan Van de Ven
Ditto for Bokeh.
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Julian Taylor]

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.

Post by David Cournapeau
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
pandas is going to drop
2.6 and 3.3 next release at end of Jan
(3.2 dropped in 0.17, in October)
I can be reached on my cell 917-971-6387

Post by Bryan Van de Ven

Post by Eric Firing
Chuck,
I would support dropping the old versions now. As a related data

point, matplotlib is testing master on 2.7, 3.4, and 3.5--no more
2.6 and 3.3.

Post by Bryan Van de Ven
Ditto for Bokeh.
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

Post by Julian Taylor
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.

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

[Bryan Van de Ven]

Post by Julian Taylor
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.
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 statement.
• A new version of the io library, rewritten in C for performance.
• The ordered-dictionary type described in PEP 372: Adding an Ordered Dictionary to collections.
• The new "," format specifier described in PEP 378: Format Specifier for Thousands Separator.
• The memoryview object.
• A small subset of the importlib module, described below.
• The 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() function is also now correctly rounded.
• The PyCapsule type, used to provide a C API for extension modules.
• The 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.

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

[Charles R Harris]

Post by Charles R Harris

On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor <
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.
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 statement.
• A new version of the io library, rewritten in C for performance.
• The ordered-dictionary type described in PEP 372: Adding an

Ordered Dictionary to collections.

• The new "," format specifier described in PEP 378: Format

Specifier for Thousands Separator.

• The memoryview object.
• A small subset of the importlib module, described below.
• The 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() function is also now correctly rounded.

• The PyCapsule type, used to provide a C API for extension

modules.

• The 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.
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
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.
"""

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

[Sturla Molden]

Post by Charles R Harris
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.

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

[Chris Barker]

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

Post by Sturla Molden

Post by Charles R Harris
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

Post by Charles R Harris
the releases go.
I would like to here from the scipy folks first.

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
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
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

***@noaa.gov

[Ralf Gommers]

Post by Chris Barker
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

Post by Sturla Molden

Post by Charles R Harris
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

Post by Charles R Harris
the releases go.
I would like to here from the scipy folks first.

+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

Post by Chris Barker

Post by Sturla Molden
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
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
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Charles R Harris]

Post by Ralf Gommers

Post by Chris Barker
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

Post by Charles R Harris

Post by Charles R Harris
As a strawman proposal, how about dropping moving to 2.7 and 3.4

minimum

Post by Charles R Harris
supported version next fall, say around numpy 1.12 or 1.13 depending

on how

Post by Charles R Harris
the releases go.
I would like to here from the scipy folks first.

+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.

OK, I'll go ahead and add a heads up to the 1.11.0 release notes that
support for Python 2.6, 3.2, and 3.3 will be dropped in 1.12.0

<snip>

Chuck

[Erik Bray]

On Tue, Dec 8, 2015 at 6:51 PM, Charles R Harris

Post by Charles R Harris

Post by Ralf Gommers

Post by Chris Barker
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

Post by Charles R Harris
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.

+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.

OK, I'll go ahead and add a heads up to the 1.11.0 release notes that
support for Python 2.6, 3.2, and 3.3 will be dropped in 1.12.0

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/

[Julian Taylor]

Post by Chris Barker
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

Post by Charles R Harris
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.

+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

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.

[Paul Hobson]

On Thu, Dec 10, 2015 at 4:20 AM, Julian Taylor <

Post by Chris Barker
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

Post by Charles R Harris
As a strawman proposal, how about dropping moving to 2.7 and

3.4 minimum

Post by Charles R Harris
supported version next fall, say around numpy 1.12 or 1.13

depending on how

Post by Charles R Harris
the releases go.
I would like to here from the scipy folks first.

+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

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.

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

[Christoph Deil]

Post by Chris Barker
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

Post by Charles R Harris
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.

+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
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.
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
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion <https://mail.scipy.org/mailman/listinfo/numpy-discussion>

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

[Nathaniel Smith]

Post by David Cournapeau
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
https://caremad.io/2015/04/a-year-of-pypi-downloads/

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

[David Cournapeau]

Post by Nathaniel Smith

Post by David Cournapeau
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
https://caremad.io/2015/04/a-year-of-pypi-downloads/

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...

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

[Aldcroft, Thomas]

Post by David Cournapeau

Post by Nathaniel Smith

Post by David Cournapeau
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

Post by David Cournapeau
https://caremad.io/2015/04/a-year-of-pypi-downloads/

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...

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

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

Post by David Cournapeau
David
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion