[Python-Dev] PEP 0404 and VS 2010 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Nov 21 15:53:07 CET 2013

On 22 November 2013 00:16, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:

> For Stackless, neither argument applies because 2.8 work would be done > by us and stackless has no particular allegiance towards either version.

Stackless can release their own Stackless 2.8 if they want, but I don't get why CPython would have a 2.8 too. Oh, this is the misunderstanding. No one is trying to get permission for "CPython 2.8", only "Stackless Python 2.8". The "namespace" question from Christian has to do with a "python28.dll" which would be built using VS2010, that this would never clash with a CPython version built the same way. such clashes would be very unfortunate. Of course, we could even make a full break, if there will never be a CPython 2.8 (which there won't be) and call the dll slpython28.dll.

OK, rereading Christian's original post, I think we may need to understand the problem you are trying to solve a little better. If I have understood correctly,

  1. Currently CPython 2.7 only officially supports building with Visual Studio 2008. This is due to the ABI instability of the Windows CRT and the fact that elements of the CRT ABI are republished as part of the Python ABI.

  2. (CCP?) customers are wanting to build CPython from source, and don't care about compatibility with binary extensions built by others in the normal way against the regular CPython release. If they need extensions, they will build them from source themselves, thus avoiding any CRT ABI incompatibility issues.

If this interpretation is correct, then Martin's suggestion of a different DLL name entirely should work for your use case. Something like:

slpy27cr100.dll ("Stackless Python 2.7 for Visual Studio 2010")
slpy27cr110.dll ("Stackless Python 2.7 for Visual Studio 2013")

If there's no need for a compatible ecosystem of C extensions (e.g. it's being embedded as part of a large application which takes care of linking everything properly), then the problem becomes much simpler, and there's a much higher chance it can be handled upstream in CPython itself.

The only thing that can't happen is to build a python27.dll that links against a newer C runtime than the Visual Studio 2008 one.

I believe this approach would be substantially less confusing for the broader community than trying to explain that a 2.8 release of Stackless Python was really just a version bump for the Windows CRT ABI.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list