Python version coexistence on WIndows

[David Bolen]

"Tim Peters" <tim.one at home.com> writes:

> [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:

Yep - but it's infrequent enough that I haven't bothered yet.  I
normally don't even bother with the icons (I'll take any version :-)),
so it's just like 3 entries to tweak.

> 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.

Always wondered about this - I understand how it hides the right
version beneath the generic 'pywintypes' and 'pythoncom', but can't
quite figure out why simple modules of those names that conditionally
imported the right version wouldn't work as well and lose the registry
requirements.

> 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.

Yep - I generated the patch for 2.0 to at least stop it from crashing
when you had an older extension you tried to import :-)

>                                                          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.

Hmm - I think I remember a lot of python-dev discussions at the time
about version identification dynamically to better share the same DLL.
The other option of course is to number the Python DLL based on its
binary API compatibility - more like .so numbering under Unix.  You'd
still change occasionally but less frequently.

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

Makes me think of the day I finally gave up trying to keep my OS
separate from my applications and just started accepting the "C:"
based defaults for all the installation packages :-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/