version-number dependency in extensions (was Re: ConfigParser module in 1.52 is buggy?)

[Mark Hammond]

[tim]
> A PEP is *always* a fine idea <wink>.  I'd like to see Mark write a
> rationale for the current Windows design too, beyond that it's convenient
> for Python developers to have 20 versions of Python sitting on
> one box; the

That is the only rationale that exists.  I have had discussions with people
who are not happy with an upgrade forcing _all_ their Python code to migrate
to the new version at the instant they install a Python upgrade.

It is not uncommon for people to be running a number of important Python
"applications" on their PC.  Note that by "applications" here I don't mean
commercially packaged apps like Komodo that _do_ use their own Python -
often it is simply a collection of scripts that the users run under a
standard Python installer.

By sticking with a simple "python.dll", people will be very scared to
upgrade at the risk of breaking a number of their significant apps all at
the same time.  Using a different DLL name means that the users can migrate
on a per application basis.

The underlying problem is that python[xx].dll lives in the System32
directory.  I'd love to fix this, but it has come up a few times and no
reasonable solution has been forthcoming that still allows COM to work.
There is nothing inherently complex about this COM requirement - just
consider that suddenly Excel or Word suddenly become "Python embedders",
even though they have no builtin knowledge of Python.

In a nutshell, when a Python COM object is registered, a reference to
"pythoncom[xx].dll" is added to the registry.  If this is placed in the
Python directory itself, the pythoncom[xx].dll is found fine, but this DLL
references python[xx].dll.  Even if python[xx].dll lives in the same
directory as pythoncom[xx].dll, Windows refuses to find python[xx].dll.  If
COM used LoadLibraryEx() to locate the COM dlls, life would probably be
good.  However, it appears not to.  In the case of Excel for example, the
"application directory" is clearly not Python's directory.  LoadLibrary's
search rules prevent python[xx].dll from being located unless it is on the
path or in the app directory.

I'm really happy to work on a way of avoiding this.  It bites me very
regularly.  Some schemes that use magic redirection from a stub python.dll
have been discussed, but they never went anywhere as any that would work
require some magic to ensure that only a single Python[xx].dll is used for a
single app regardless of how many [xx]s actually exist, and regardless of
how the application was started.  There was a thread about this on
Python-dev around 12 months ago.  It starts at
http://mail.python.org/pipermail/python-dev/2000-April/003065.html

Mark.