Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Charles R Harris <charlesr.harris <at> gmail.com>
Subject: Re: When to stop supporting Python 2.6?
Newsgroups: gmane.comp.python.numeric.general
Date: Sunday 6th December 2015 23:41:31 UTC (about 1 year ago)
On Fri, Dec 4, 2015 at 9:29 AM, Bryan Van de Ven 
wrote:

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

> wrote:
> >
> >
> >
> > On Fri, Dec 4, 2015 at 2:40 AM, Julian Taylor <
> [email protected]> 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.
> """
>
>
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
 
CD: 3ms