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

[Nick Coghlan]

On 19 January 2014 11:13, Neil Schemenauer <nas-python at arctrix.com> 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.

Red Hat will offer commercial Python 2 support until at least 2023
(since the RHEL7 beta was just released with Python 2.7 as the system
Python and the current lifecycle for RHEL releases is 10 years), and I
expect other commercial redistributors will similarly extend the
lifetime of Python 2 well beyond 2015 when the level of support we
provide for free reverts to security fix only mode. With CentOS and
other downstream community rebuilds of RHEL available, this even
includes the availability of *free* prebuilt versions.

So Python 2 application developers don't have anything to worry about
*if they're happy with Python 2.7 as it stands*, especially after
accounting for the Python 3 standard library modules that are also
available on PyPI for Python 2 (or are relatively easy to fork and
port back to Python 2, or just copy and paste the relevant code into a
private utility module).

However, now that we're approaching the release of Python 3.4 (the
second Python 3 release without a corresponding Python 2 release),
some Python 2 developers are finally beginning to realise how much
they had come to rely on the relatively steady cadence of new features
and functionality previously delivered in an easily consumable bundle
by the CPython core development team.

So, those developers are now faced with a few different options:

- invest in migrating to Python 3 themselves (the cost of which will
vary from being similar to any major Python version update, with most
of the cost being in compatibility testing, to substantially more
expensive, depending on the exact nature of the application, its
dependencies and the quality of their respective test suites)
- try to guilt the existing core developers into creating Python 2.8
for them for free (not going to happen, read PEP 404)
- try to hire enough of the core developers to convince Guido to
approve a Python 2.8 release from python.org (not impossible, but
likely prohibitively expensive, since most, perhaps all, of the core
development team are already gainfully employed elsewhere)
- fork CPython to create their own Python 2.8 (also cost prohibitive
from a time and materials perspective, unless you already have the
infrastructure and community in place to maintain a CPython fork)

That last point is relevant to the discussions around Stackless 2.8:
CCP and the rest of the Stackless community have been maintaining a
CPython fork for so long that the idea of porting some of the
backwards compatible Python 3.3 and 3.4 changes over to a Stackless
2.8 release is a relatively straightforward one for them and something
they're seriously considering. However, significant compatibility
testing costs would still be incurred in a switch from CPython 2.7 to
Stackless 2.8, so conservative developers are still likely to stick
with the devil they know (most of the really interesting changes in
Python 3 are the backwards incompatible ones, so they won't be
backported, even in Stackless 2.8).

There's lots and lots of info about the state of the Python 3
transition here:
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

I'd call reading that Q&A the starting point for any discussion of
creating a Python 2.8 release, but it really isn't. The starting point
is a deep understanding behind the business drivers of open source
based commercial operations and how they deal with cases where they
depend on things that upstream has decided not to support any more.
Sometimes they invest in the infrastructure needed to create their own
fork (since their motivations no longer align with the existing
development team's motivations), sometimes they pay commercial
redistributors to continue supporting the older version (an approach I
appreciate, since it represents one of the things that ultimately gets
me paid), sometimes they approach the existing development team (or a
related foundation) about directly funding continued development of
the version being discontinued and sometimes they decide to invest in
updating to the newer platform themselves.

This dynamic isn't unique to open source though, as it impacts even
large proprietary platform vendors like Microsoft - Windows XP almost
certainly remained supported for so long because a whole lot of paying
users that weren't happy with the state of Windows Vista and offered
Microsoft enough money to ensure they could keep using Windows XP
until Windows 7 was available. The only difference there is that in
the proprietary case, the *only* option users have is to beg the
vendor to continue maintenance - the options of forking or paying
someone else to take up maintenance aren't available due to the
licensing restrictions on the proprietary platform.

Returning to the Python 3 case, as things currently stand, the
combination of Armin Ronacher's python-modernize with Benjamin
Petersen's six module is one approach to smooth migration, as is Ed
Schofield's python-future module and its futurize tool. For
application porting (which may be able to just drop Python 2 support
rather than needing to maintain Python 2 and Python 3 support in
parallel), Guido's original 2to3 conversion tool may suffice.

PEP 461 will likely add a binary interpolation feature *back* to
Python 3.5, removing an additional blocker to forward migrations for
current Python 2 users (just as PEP 414 did by restoring Unicode
literal support).

While the Stackless community are looking at creating a Stackless 2.8
release, and some Python 2 users may decide it is worth migrating to
the Stackless fork to gain access to any Python 3 features they decide
to backport, rather than migrating to Python 3 itself, this is all
perfectly fine - it's the open source model working *exactly as it is
supposed to*, by giving people the option to take steps that meet
*their* needs, rather than being completely subject to the desires of
the core development team.

The only thing people *don't* get to do is make suggestions about what
*should* happen without also explaining:

* what problem the suggestion is designed to solve, and how it
actually helps to solve it
* how the proposal is going to be resourced, especially when it is
something the existing development team have disclaimed any interest
in doing for free

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia