[Python-Dev] PEP 0404 and VS 2010

[martin at v.loewis.de]

Quoting Barry Warsaw <barry at python.org>:

> On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
>
>> Many customers are forced to stick with Python 2.X because of other  
>> products,
>> but they require a Python 2.X version which can be compiled using Visual
>> Studio 2010 or better.  This is considered an improvement and not a bug fix,
>> where I disagree.
>
> I'm not so sure about that.  Python 2.7 can still get patches to help extend
> its useful life by allowing it to be built with newer compiler suites.  I
> believe this has already been done for various Linux compilers.  I see no
> non-technical reason why Python 2.7 can't be taught how to build with VS 2010
> or newer.

Unfortunately, there are severe *technical* reasons that make this a  
challenge.
If they wouldn't exist, we would have done this long ago.

The problem is in the ABI, and the question which msvcrt python27.dll links
with. With official support for VS 2010, there would be two ABI-incompatible
releases of Python on Windows; entirely different from supporting a new
version of gcc (say), as newer gccs will typically be binary-compatible
with older releases (I admit I don't understand the ABI compatibility on OSX).

So adding VS 2010 build files to the 2.7 tree would be fine with me, but I
doubt users are helped with that - they want a binary release that uses them.
Releasing this as "Python 2.7", with a "python27.dll" would lead right to
DLL hell.

I could imagine having a separate release that is called "Python 2.7 for
Visual Studio 2010" (and then another one called "Python 2.7 for Visual
Studio 2013"). They could give different names to the Python DLL, e.g.
py27cr100.dll and py27cr110.dll.

Whether this would be a good idea or not, I don't know. It would create
separate ecosystems for different releases of Python 2.7 for different
CRTs. Package authors would have to create multiple binary releases of
the same modules for Windows, and upload them to PyPI. pip would have
to learn to download the right one, depending on what build of Python
2.7 is running.

I'm skeptical that using "Python 2.8" as the release name would help
in the long run. Assuming this is done for VS 2010, then "Python 2.9"
will have to be released for binary compatibility with VS 2013,
and "Python 2.10" for VS 2016, assuming Python 2.7 is then still
around by that time.

Regards,
Martin