On 19 January 2014 11:13, Neil Schemenauer
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_an... 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@gmail.com | Brisbane, Australia