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

On Dec 3, 2015, at 6:00 PM, Bryan Van de Ven wrote:

...

On Dec 3, 2015, at 4:59 PM, Eric Firing wrote:

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

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:

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 mailto:jeffreback@gmail.com> wrote:

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 > On Dec 3, 2015, at 6:00 PM, Bryan Van de Ven mailto:bryanv@continuum.io> wrote: > > >> On Dec 3, 2015, at 4:59 PM, Eric Firing mailto:efiring@hawaii.edu> wrote: >> >> 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 > NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

On Dec 4, 2015, at 9:49 AM, Charles R Harris wrote:

On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor 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.

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

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

On Wed, Dec 9, 2015 at 12:01 AM, Chris Barker wrote:

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 wrote:

...

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

+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

...

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

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

--

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

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

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

On Tue, Dec 8, 2015 at 4:10 PM, Ralf Gommers wrote:

...

On Wed, Dec 9, 2015 at 12:01 AM, Chris Barker wrote:

...

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 wrote:

...

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

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

On Thu, Dec 10, 2015 at 4:20 AM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:

On 12/09/2015 12:10 AM, Ralf Gommers wrote:

...

On Wed, Dec 9, 2015 at 12:01 AM, Chris Barker mailto:chris.barker@noaa.gov> wrote:

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 mailto:sturla.molden@gmail.com> wrote:

Charles R Harris mailto:charlesr.harris@gmail.com> 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.

+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

On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau wrote:

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/

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 6:13 AM, David Cournapeau wrote:

On Fri, Dec 4, 2015 at 11:06 AM, Nathaniel Smith wrote:

...

On Fri, Dec 4, 2015 at 1:27 AM, David Cournapeau wrote:

...

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/

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

David

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