[Python-Dev] PEP 0404 and VS 2010

[Nick Coghlan]

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