Python version coexistence on WIndows

Tim Peters tim.one at home.com
Wed Aug 8 00:13:15 EDT 2001


[David Bolen]
> ...
> I've found the only real conflict with multiple versions in the
> registry is with file extension registration - where the most
> recent version of Python I've installed "wins".  That only comes into
> play if you let Windows pick your Python interpreter - you can always
> explicitly run a specific Python version against a script.  In the
> end, I typically just edit the file associations to make them default
> to the version I want as the default.

If you (or Mats) do this often, it's sure easier to create a .reg file to do
it for you.  For example, for 2.1 or 2.1.1 installed in C:\Python21:

-------------------- snip here
REGEDIT4

[HKEY_CLASSES_ROOT\Python.File]
@="Python File"
[HKEY_CLASSES_ROOT\Python.File\DefaultIcon]
@="C:\\Python21\\Py.ico"
[HKEY_CLASSES_ROOT\Python.File\shell\open\command]
@="C:\\Python21\\python.exe \"%1\" %*"

[HKEY_CLASSES_ROOT\Python.NoConFile]
@="Python File (no console)"
[HKEY_CLASSES_ROOT\Python.NoConFile\DefaultIcon]
@="C:\\Python21\\Py.ico"
[HKEY_CLASSES_ROOT\Python.NoConFile\shell\open\command]
@="C:\\Python21\\pythonw.exe \"%1\" %*"

[HKEY_CLASSES_ROOT\Python.CompiledFile]
@="Compiled Python File"
[HKEY_CLASSES_ROOT\Python.CompiledFile\DefaultIcon]
@="C:\\Python21\\pyc.ico"
[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open\command]
@="C:\\Python21\\python.exe \"%1\" %*"

[HKEY_CLASSES_ROOT\.py]
@="Python.File"
"Content Type"="text/plain"

[HKEY_CLASSES_ROOT\.pyw]
@="Python.NoConFile"
"Content Type"="text/plain"

[HKEY_CLASSES_ROOT\.pyc]
@="Python.CompiledFile"
-------------------- snip here

Stick that in a file, like python21.reg.  When you want to restore the 2.1
file associations, right-click on python21.reg in Explorer and select Merge
from the context menu.

Or type

    regedit /s python21.reg

at a command prompt -- the "/s" is for "silent".

Under Win2K (but nothing else), it also works to store these things under
HKEY_CURRENT_USER\Software\Classes (mirroring that HKEY_CLASSES_ROOT is just
a shorthand for HKEY_LOCAL_MACHINE\Software\Classes).  HKCR under Win2K is a
merged view of HKLM's Software\Classes and HKCU's, with the latter "winning"
in case of duplicates.  This allows each acct its own beliefs about what
file extensions mean.  Fiddle the .reg file in the obvious ways if that's
desirable.

> Since everything else is under a version specific Python tag in the
> registry (or in the start menu), even with the default registry
> adjusting installers, I've got 1.5.2, 2.0.1, 2.1.1 and 2.2a1 installed
> simultaneously without any problems.  Note that multiple revisions of
> the same version (e.g., 2.2a1 and any future 2.2a2 for example) will
> have other conflicts as they use the same keys which are only
> major.minor.

This is deliberate, but only Mark Hammond understands it <0.8 wink>.

> The win32all extensions do really seem to need the registry (at the
> least to find some magic modules),

Ditto.

> but they are also versioned (so the DLLs don't conflict in the system
> directory) and installed beneath the appropriate Python key for the
> version of the extensions, so I haven't had any problem with them
> either.

A mixed blessing:  since extension modules compile-in the name of the main
Python DLL they use, every time we bump a minor version number our Windows
users *have* to get freshly-compiled extension modules.  We've stuck to the
"about 6 months between .minor" releases we wanted to achieve when Guido
left CNRI, and that DLL renaming scheme was invented when releases were
slower-paced.  People on Windows would probably riot if they learned that
Unix users usually don't have to upgrade extensions -- so I'm not going to
mention it <wink>.  The major.minor dependence on Windows is artificial,
rarely reflecting an actual incompatibility.

PEP material there, if someone cares enough to wrestle with the issues.

> I run most stuff with Cygwin/bash, so I have a few bash aliases that
> run the right interpreter against a script when I want to pick
> explicitly, and some others that temporarily adjust paths to default
> to the right installation directories.  The same could be done with
> .cmd files (or .bat files).

Even in a plain command.com DOS box (which is as plain as such things get),
I usually just type the path to the Python I want, when it matters (not
often!).  Else I have this trivial py.bat in my \bin directory:

\python21\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

Twice per year, I change one letter in it <wink>.

windows-is-easy-if-you-don't-fight-it-ly y'rs  - tim





More information about the Python-list mailing list