[Python-Dev] PEP 0404 and VS 2010

Nick Coghlan ncoghlan at gmail.com
Fri Nov 22 10:01:03 CET 2013

On 22 Nov 2013 10:58, "Steve Dower" <Steve.Dower at microsoft.com> wrote:
> Nick Coghlan wrote:
> > For 2.7.7, I think some combination of the two following ideas would be
> > pursuing:
> > - a C runtime independent API flag (set by default on Windows when
building with
> > a compiler other than VS2008). This would largely be a backport of some
of the
> > stable ABI work from Python 3.
> > - getting Windows closer to the current Mac OS X situation by ensuring
that the
> > C runtime used directly affects the ABI flags and shared library names.
> > would apply the Mac OS X guideline where extensions are expected to be
> > compatible with the python.org binaries.
> 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.
> 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.
> This should let any compiler be used for building extensions or hosting
python27.dll without affecting existing code or requiring changes to the
> > This would be the biggest change pushed through under the "make builds
> > policy for the extended 2.7 lifecycle, but Microsoft's aggressive
approach to
> > deprecating old compilers and C runtimes means I think we don't have
> > choice.
> 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.
> > In the near term, if Stackless build to a different DLL name under
VS2010 and
> > make it clear to their users that extension compatibility issues are
> > (or even likely) if they aren't rebuilt from source, then I think that
would be
> > compatible with the above proposal for a way forward.
> > Then we'd just need some volunteers to write and implement a PEP or two
> 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.

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 :)


> Cheers,
> Steve
> > (Note, similar to the Mac OS X situation, I think we should do this
> > hosting any new interpreter variants on python.org - VS2010 and VS2013
> > builds would become separate build-from-source ecosystems for
extensions, using
> > sdists on PyPI as the default distribution mechanism)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131122/83a53272/attachment.html>

More information about the Python-Dev mailing list