[Python-Dev] Moving Python 3.5 on Windows to a new compiler

[Donald Stufft]

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

> On 7 June 2014 08:43, Sturla Molden <sturla.molden at gmail.com> wrote:
>> Brett Cannon <bcannon at gmail.com> wrote:
>> 
>>> Nope. A new minor release of Python is a massive undertaking which is why
>>> we have saved ourselves the hassle of doing a Python 2.8 or not giving a
>>> clear signal as to when Python 2.x will end as a language.
>> 
>> Why not just define Python 2.8 as Python 2.7 except with a newer compiler?
>> I cannot see why that would be massive undertaking, if changing compiler
>> for 2.7 is neccesary anyway.
> 
> It's honestly astonishing the number of people that tell us doing a
> new minor release of Python 2 is easy, and then refuse to believe us
> when we tell them it isn't.
> 
> It's 2014 and Python *2.7*, which was released in *2010*, is STILL
> BEING ROLLED OUT. One part of the rollout that is near & dear to my
> own heart is the fact that Red Hat Enterprise Linux 7 and CentOS 7 are
> still in their respective release candidate phases, and it is the 6 ->
> 7 transition that finally upgrades their system Pythons from 2.6 to
> 2.7. Maya 2014 & MotionBuilder 2014 are also the first versions
> Autodesk are shipping that use 2.7 rather than 2.6 as the scripting
> engine (although my understanding is that Autodesk don't guarantee
> compatibility with Python C extensions that aren't built specifically
> for use with their products, so they already use a newer C runtime on
> Windows than we do).
> 
> And once those two dominoes fall, then there'll be some additional
> follow on upgrade work in some parts of the developer community as the
> *users* that receive their Python through those channels rather than
> directly from upstream switch from 2.6 to 2.7 and stumble over the
> small compatibility breaks between those two releases.
> 
> 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.

> 
> That said, there are definitely problems with toolchain availability
> on Windows for Python 2, and it isn't clear yet how that will be
> addressed in the long run. Steve is working on ensuring the official
> toolchain and C runtime binaries are more readily available from MS.
> Other folks are independently looking into ensuring that open source
> toolchains (like mingw) can be used effectively to at least build
> Python C extensions for Windows (and ironing out some of the glitches
> with that approach that others have mentioned). The Python Packaging
> Authority are continuing to work on the wheel based infrastructure to
> help avoid end users having to compile anything in the first place,
> and redistributors like ActiveState, Enthought & Continuum Analytics
> also make it possible for many end users to just ignore these upstream
> concerns. An extension compatibility break would be an absolutely last
> resort, pursued only if all other attempts at resolving the challenges
> have demonstrably failed - even at the best of times it can take
> months for C extension authors to start publishing compatible binaries
> for a new minor release, so we'd have to assume that time would be
> even longer for a Python 2.7 maintenance release, if they published
> updated binaries at all.
> 
> Regards,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io


-----------------
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/7ad85492/attachment.sig>