[Python-Dev] Moving Python 3.5 on Windows to a new compiler (original) (raw)

Donald Stufft donald at stufft.io
Sat Jun 7 07:05:19 CEST 2014

On Jun 7, 2014, at 12:58 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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

I’m not sure I agree, the porting docs only show a subset of changes, you also have a lot of new stuff like OrderedDict, dict comprehensions, set literals, argparse, dict views, memory views, etc. AFAIK stable releases don’t jump versions because all of these new features are risks, not because a number didn’t change.

I don’t particularly care too much though, I just think that bumping the compiler in a 2.7.Z release is a really bad idea and that either of the other two options are massively better.

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

Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mail.python.org/pipermail/python-dev/attachments/20140607/474f508c/attachment-0001.sig>

More information about the Python-Dev mailing list