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

[Bryan Van de Ven]

> On Dec 4, 2015, at 9:49 AM, Charles R Harris <charlesr.harris at gmail.com> wrote:
> 
> 
> 
> On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor <jtaylor.debian at googlemail.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.
> 
> 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