Nick Coghlan wrote:
> For 2.7.7, I think some combination of the two following ideas would be worth
> 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. PyPI
> 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 
packages.

> This would be the biggest change pushed through under the "make builds work"
> 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 much
> 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 possible
> (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. 

Cheers,
Steve

> (Note, similar to the Mac OS X situation, I think we should do this without
> hosting any new interpreter variants on python.org - VS2010 and VS2013 source
> builds would become separate build-from-source ecosystems for extensions, 
> using
> sdists on PyPI as the default distribution mechanism)
_______________________________________________
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

Reply via email to