[Python-ideas] Create Python 2.8 as a transition step to Python 3.x

Steven D'Aprano steve at pearwood.info
Sun Jan 19 03:04:04 CET 2014


On Sat, Jan 18, 2014 at 07:13:32PM -0600, Neil Schemenauer wrote:
> On 2014-01-18, Terry Reedy wrote:
> > On 1/17/2014 10:22 PM, Neil Schemenauer wrote:
> > >The transition to Python 3 is happening but there is still a massive
> > >amount of code that needs to be ported.
> > 
> > For application code, why does it need to be ported.
> 
> Unless Python 2.x is going to be maintained in perpetuity then code
> will have to be ported.  This point seems obvious to me.

Why? If it isn't broken, don't break it. At last year's US PyCon, there 
was at least one person still using Python 1.5 in production. Doing so 
means that he gets no bug fixes or security updates for 1.5, but if he 
doesn't need them, that is no loss.

Python 2.7 will almost certainly still be supported by (for example) Red 
Hat until 2023, which is probably longer than most applications will be 
still in use.


> > For many application areas, the text problem seems to have been
> > somewhat solved, to the point where people are writing 2&3 code
> > successfully.
> 
> Sure you can write code that's compatible with 2&3, that's not the
> code I'm talking about.  I'm talking about the millions (maybe
> billions) of lines of existing Python code.
> 
> > I think it too late now.
> 
> I disagree.  The amount of Python 2 code that exists exceeds the
> amount of Python 3 by orders of magnitude.  That existing codebase
> either stops evolving and stays Python 2 forever 

Why is that a problem? Some people will never migrate away from Python 
2.7/2.5/2.4/1.5. That's okay. A few months ago I ported an application 
from 2.3 to 2.6. It's not well recognised that Python 3 is not the first 
time Python broke backwards compatibility: string exceptions

raise "This is an error"

became a warning in 2.5 (I think) and a SyntaxError in 2.6. This 
application made extensive use of string exceptions. My customer was 
happy with 2.3 code for years, until they upgraded their server to a 
version of Centos with 2.6, and that was the only reason they upgraded. 
I expect they will stick with 2.6 until such time as they upgrade the 
server again in another decade or so, and that's fine. They may never 
upgrade, and that's fine too.


> or we do all that's
> practical to help people move it to a current version of Python.

Define "all that's practical". How much hand-holding do they need? On 
the Python-Dev list, there are *hundreds* of emails about this issue, 
which is distracting the core devs from making Python 3 even more 
awesome.

[...] 
> I don't give a shit what it's called.  A Python 2 fork is going to
> happen whether the PSF blesses it or not

I doubt that. Stackless may try to call itself Python 2.8, but it won't 
be porting Python 3 features:

https://mail.python.org/pipermail/python-dev/2013-November/130421.html

Stackless wanted to release a 2.8, but it wouldn't contain any 
additional Py3 features:

https://mail.python.org/pipermail/python-dev/2013-November/130421.html

it would be a version bump to support a newer Microsoft compiler.

There are plenty of people who *say* they want a Python 2.8 with half 
the Python 3 features, but nobody as far as I can see is actually 
willing to do the work. If they were, why haven't they started? They 
don't need permission.



-- 
Steven



More information about the Python-ideas mailing list