[Python-Dev] Python 2.7 patch levels turning two digit (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Mon Jun 23 22:31:41 CEST 2014

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

More information about the Python-Dev mailing list