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

[Brian Curtin]

On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 06.06.2014 20:25, Brian Curtin wrote:
>> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
>>>> Chris Angelico wrote:
>>>>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
>>>>>> What this means for Python is that C extensions for Python 3.5 and later can be built using any version of MSVC from 14.0 and later.
>>>>>
>>>>> Oh, if only this had been available for 2.7!! Actually... this means that 14.0 would be a good target for a compiler change for 2.7.x, if such a change is ever acceptable.
>>>>
>>>> Maybe, but I doubt it will ever be acceptable :)
>>>
>>> Well, there were discussions. Since Python 2.7's support is far
>>> exceeding the Microsoft promise of support for the compiler it was
>>> built on, there's going to be a problem, one way or the other. I don't
>>> know how that's going to end up being resolved.
>>
>> We're going to have to change it at some point, otherwise we're going
>> to have people in 2018 scrambling to find VS2008, which will be 35
>> versions too old by then. No matter what we do here, we're going to
>> have a tough PR situation, but we have to make something workable. I'd
>> rather cause a hassle than outright kill extensions.
>>
>> I would probably prefer we aim for VS 14 for 3.5, and then explore
>> making the same change for the 2.7.x release that comes after 3.5.0
>> comes out. Lessons learned and all that.
>
> Are you sure that's an option ? Changing the compiler the stock
> Python from python.org is built with will most likely render
> existing Python extensions built for 2.7.x with x < (release that comes
> after 3.5.0) broken, so users and installation tools will end up
> having to pay close attention to the patch level version of Python
> they are using... which is something we wanted to avoid after
> we ran into this situation with 1.5.1 and 1.5.2 a few years ago.

None of the options are particularly good, but yes, I think that's an
option we have to consider. We're supporting 2.7.x for 6 more years on
a compiler that is already 6 years old. Something less than awesome
for everyone involved is going to have to happen to make that
possible.