[Python-Dev] Python 2.7 patch levels turning two digit

["Martin v. Löwis"]

Am 23.06.14 21:53, schrieb Ned Deily:
> It does seem like a conundrum.  As I have no deep Windows experience to 
> be able to have an appreciation of all of the technical issues involved, 
> I ask out of ignorance: would it be possible and desirable to provide a 
> transition period of n 2.7.x maintenance releases (where n is between 1 
> and, say, 3) where we would provide 2 sets of Windows installers, one 
> set (32- and 64-bit) with the older compiler and CRT and one with the 
> newer, and campaign to get users and packagers who provide binary 
> extensions to migrate? 

The question is how exactly you implement the transition. I see two
alternatives:
1. "Hijack" the 2.7 name space, in particular the name "python27.dll",
   along with registry keys, the .pyd extension, etc.
   Doing so would permit users to mix binaries from different compilers,
   and doing so would lead to crashes. Users would have to be careful
   to either install packages built for the old compiler or packages
   for the new compiler, and never mix.
2. "Sandbox" the 2.7 name space; come up with new names for everything.
   E.g. "python27vs13.dll", ".pydvs13" (or "_vs13.pyd"),
   "C:\Python27vs13", along with the corresponding changes to PyPI,
   pip, buildout, etc. which would need to learn to look for the right
   variant of a Python 2.7 package.
   This should work, but might take several years to implement: you
   need to find all the places in existing code that refer to the
   "old" names.
   If you do it right, you are done about the time when VS 13 becomes
   unavailable, so you'd then do another such transition to VS 2015,
   which promises forward-binary compatibility to future releases of
   Visual Studio.

> Would that mitigate the pain, assuming that 
> Steve (or someone else) would be willing to build the additional 
> installers for the transition period?  I've done something similar on a 
> smaller scale with the OS X 32-bit installer for 2.7.x but that impact 
> is much less as the audience for that installer is much smaller.

Well, the question really is whether precompiled extension modules
available from PyPI would work on both compilers. I understand that
for OSX, you typically don't have precompiled binaries for the extension
modules, so installation compiles the modules from scratch. This is
easier, as it can use the ABI of the Python which will be installed
to.

If you go the "parallel ABIs" route, extension authors have to provide
two parallel sets of packages as well. Given 32-bit and 64-bit packages,
this will make actually two additional packages - just as if they had
to support another Python version.

Regards,
Martin