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

[M.-A. Lemburg]

On 06.06.2014 20:49, Brian Curtin wrote:
> 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.

Perhaps we could combine this with the breakage that a Python 2.7.10
would introduce due to the two digit patch level release version ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 06 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-05-28: Released mxODBC.Connect 2.1.0 ...     http://egenix.com/go56
2014-07-02: Python Meeting Duesseldorf ...                 26 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/