On 22 Nov 2013 10:58, "Steve Dower"
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
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
worth that 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
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
work" that Python 2.7 is prepared for an unknown future.
In the near term, if Stackless build to a different DLL name under
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
VS2010 and possible 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, Nick.
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
without source
builds would become separate build-from-source ecosystems for extensions, using sdists on PyPI as the default distribution mechanism)