[Python-Dev] 2.7 is here until 2020, please don't call it a waste.

Christian Heimes christian at python.org
Sat May 30 01:49:10 CEST 2015


On 2015-05-29 23:14, Gregory P. Smith wrote:
> 
> On Fri, May 29, 2015 at 12:24 AM Nick Coghlan <ncoghlan at gmail.com
> <mailto:ncoghlan at gmail.com>> wrote:
> 
> 
>     On 29 May 2015 11:01 am, "Victor Stinner" <victor.stinner at gmail.com
>     <mailto:victor.stinner at gmail.com>> wrote:
>     >
>     > Why not continue to enhance Python 3 instead of wasting our time with
>     > Python 2? We have limited resources in term of developers to maintain
>     > Python.
>     >
>     > (I'm not talking about fixing *bugs* in Python 2 which is fine
>     with me.)
> 
>     I'm actually OK with volunteers deciding that even fixing bugs in
>     2.7 isn't inherently rewarding enough for them to be willing to do
>     it for free on their own time.
> 
>  
> That is 100% okay.
> 
> What is not okay is for python-dev representatives to respond to users
> (in any list/forum/channel) reporting bugs in 2.7 or asking if a fix in
> 3 can be backported to 2.7 with things akin to "just use Python 3" or
> "sorry, 2.7 is critical fixes only. move to python 3 already." This is
> actively driving our largest users away.  I bring this up because a user
> was bemoaning how useless they feel python core devs are because of this
> attitude recently. Leading to feelings of wishing to just abandon
> CPython if not Python all together.
> 
> I'm sure I have even made some of those responses myself (sorry!). My
> point here is: know it. recognize it. don't do it anymore. It harms the
> community.
> 
> A correct and accurate response to desires to make non-api-breaking
> changes in 2.7 is "Patches that do not change any APIs for 2.7 are
> welcome in the issue tracker." possibly including "I don't have the
> bandwidth to review 2.7 changes, find someone on python-dev to review
> and champion this for you if you need it."  Finding someone may not
> always be easy. But at least is still the "patches welcome" attitude and
> suggests that the work can be done if someone is willing to do it. Lets
> make a concerted effort to not be hostile and against it by default.
> 
> Ex: Is someone with a python application that is a million of lines
> supposed to have everyone involved in that drop the productive work they
> are doing and spend that porting their existing application to python 3
> because we have so far failed to provide the tools to make that
> migration easy?  No.  Empathize with our community.  Feel their pain.
>  (and everyone who is working on tools to aid the transition: keep doing
> that! Our users are gonna need it unless we don't want them as users
> anymore.)
> 
> We committed to supporting 2.7 until 2020 in 2014 per
> https://hg.python.org/peps/rev/76d43e52d978.  That means backports of
> important bug or performance fixes should at least be allowed on the
> table, even if hairy, even if you won't work on them yourselves on a
> volunteer basis. This is the first long term support release of Python
> ever. This is what LTS means.  LTS could /also/ stand for Learn To
> Support...

Over the last years I have changed my mind a bit, too. For Python 2.7
LTS I welcome performance improving patches as well as security
improvements (SSL module) and build related fixes.

For performance patches we have to consider our responsibility for the
environment. Every improvement means more speed and less power
consumption. Python runs of hundreds of thousands of machines in the
cloud. Python 2.7 will be used for at least half a decade, probably
longer. Servers can be replaced with faster machines later and less
fossil fuel must be burned to produce power. Let's keep Python green! :)

Thanks to Benjamin, the patch has already landed.

Antoine's improved GIL may be another improvement for Python 2.7.
Servers are getting more cores every year. The new GIL helps to scale
multiple CPU bound threads on machines with more cores, e.g.
http://www.dabeaz.com/python/NewGIL.pdf

Christian



More information about the Python-Dev mailing list