On 06.06.2014 20:49, Brian Curtin wrote: > On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg <m...@egenix.com> wrote: >> On 06.06.2014 20:25, Brian Curtin wrote: >>> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico <ros...@gmail.com> wrote: >>>> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower <steve.do...@microsoft.com> >>>> wrote: >>>>> Chris Angelico wrote: >>>>>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower <steve.do...@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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com