Version mismatches of .PYD extensions crash python...

[Warren Postma]

What I'm wondering is, if any plans are in place to handle Win32 statically
linked Python in an EXE, and having extensions somehow handle their DLL
imports in a way that would (a) detect problems like Python 1.6 importing a
Python 1.5 PYD automatically reporting a nice descriptive error message and
(b) allow every version of Python to somehow resolve and load the correct
extension out of several available, based on versions, and (c) even allow an
extension version which is guaranteed not to break between releases because
it uses some sort of interface that will never change. I am thinking of a
COM interface here, where the interface "IPythonExtension" and
"IPythonInterpreter" interfaces (or set of interfaces) are well defined, and
when they change, we keep supporting old ones in a backwards compatible
fashion until it is impossible to do so any longer.

What would be nice for starters is if every PYD exported a function,  which
should return the major revision (15 for python 1.5) of the DLL, for
information. Also, when loading the DLL, the first thing that is done inside
the module's initialization function is to check the calling version of
Python's version number for validity. Any version mismatches should result
in a nice descriptive Python exception message, ie
"C:\Python\DLLs\MyModule.pyd failed to load: This module was written for {a
newer|an older} version of Python", rather than crashing Python entirely.

Instead, I get a crashes involving the "python thread state not set".

I realize from exploring the code internals and the global interpreter lock,
and the fact that the global lock is actually a global variable in a
different DLL, which is therefore null, and all that,  but it seems to me
that the current .PYD file mechanism is an Unstable Hack, to put it simply.
Perhaps thats because the DLL mechanisms in Windows are kind of primitive
when it comes to truly dynamic linking. I'd prefer it if extensions could
somehow intelligently manage their versions.   In fact, such problems were
what lead to Microsoft developing COM.

Could COM or a subset of COM, such as the Mozilla project's COM be the way
to build binary component interfaces for Python in the future?   Any other
Bright Ideas?

Warren Postma