<p dir="ltr"><br>
On 22 Nov 2013 10:58, "Steve Dower" <<a href="mailto:Steve.Dower@microsoft.com">Steve.Dower@microsoft.com</a>> wrote:<br>
><br>
> Nick Coghlan wrote:<br>
> > For 2.7.7, I think some combination of the two following ideas would be worth<br>
> > pursuing:<br>
> > - a C runtime independent API flag (set by default on Windows when building with<br>
> > a compiler other than VS2008). This would largely be a backport of some of the<br>
> > stable ABI work from Python 3.<br>
> > - getting Windows closer to the current Mac OS X situation by ensuring that the<br>
> > C runtime used directly affects the ABI flags and shared library names. PyPI<br>
> > would apply the Mac OS X guideline where extensions are expected to be<br>
> > compatible with the <a href="http://python.org">python.org</a> binaries.<br>
><br>
> I don't really think either of these are necessary. With some changes to Python's headers and some extra exports, it should be possible to future-proof Python 2.7.7 against any new compilers, at least on Windows.<br>

><br>
> What I have in mind is basically detecting the MSVC version in the headers (there are preprocessor variables for this) and, if it isn't VC9, substituting a different function for those that require FILE*. This function/macro could call _get_osfhandle() and pass it to an API (built into python27.dll) that calls _open_osfhandle() and forwards it to the usual API.<br>

><br>
> This should let any compiler be used for building extensions or hosting python27.dll without affecting existing code or requiring changes to the packages.<br>
><br>
> > This would be the biggest change pushed through under the "make builds work"<br>
> > policy for the extended 2.7 lifecycle, but Microsoft's aggressive approach to<br>
> > deprecating old compilers and C runtimes means I think we don't have much<br>
> > choice.<br>
><br>
> Ultimately, compilers are probably going to be deprecated more quickly now that we're on a faster release cadence, which makes it more important that Python 2.7 is prepared for an unknown future.<br>
><br>
> > In the near term, if Stackless build to a different DLL name under VS2010 and<br>
> > make it clear to their users that extension compatibility issues are possible<br>
> > (or even likely) if they aren't rebuilt from source, then I think that would be<br>
> > compatible with the above proposal for a way forward.<br>
> > Then we'd just need some volunteers to write and implement a PEP or two :)<br>
><br>
> I'm happy to work on a PEP and changes for what I described above, if there's enough interest? I can also update distutils to detect and build with any available compiler, though this may be more of a feature than we'd want for 2.7 at this point.</p>

<p dir="ltr">That's part of what a PEP can help us decide, though, so if you're willing to put one together, that would be great :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Cheers,<br>
> Steve<br>
><br>
> > (Note, similar to the Mac OS X situation, I think we should do this without<br>
> > hosting any new interpreter variants on <a href="http://python.org">python.org</a> - VS2010 and VS2013 source<br>
> > builds would become separate build-from-source ecosystems for extensions, using<br>
> > sdists on PyPI as the default distribution mechanism)<br>
</p>