On 7 June 2014 14:47, Donald Stufft <donald at stufft.io> wrote: > On Jun 7, 2014, at 12:41 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: >> >> Words like "just", or "simple", or "easy" really have no place being >> applied to a task where the time required to fully execute it with *no >> significant problems* is still measured in years. > > How much of that time exists because there were actual significant > changes from 2.6 to 2.7 and how much of it would not need to exist > if 2.8 was literally 2.7.Z with a new compiler on Windows. IOW is it > the *version* number that causes the slow upgrade, or is it the fact > that there are enough changes that it can’t be safely applied > automatically. It's the version number change itself. Python 2.7 was covered by the language moratorium, so it consists almost entirely of standard library changes, and the porting notes are minimal: https://docs.python.org/2/whatsnew/2.7.html#porting-to-python-2-7 We didn't even switch compilers on Windows (both 2.6 and 2.7 use VS 2008). I can't think of a better demonstration than the slow pace of the Python 2.7 rollout that the challenges with doing a new minor release of Python really aren't technical ones at the language level - they're technical and administrative challenges in the way the language version number interacts with the broader Python ecosystem, especially the various redistribution channels. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4