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

[Nick Coghlan]

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.

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