Version mismatches of .PYD extensions crash python...

[Martin von Loewis]

"Warren Postma" <embed at NOSPAM.geocities.com> writes:

> 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

It may be too late for 2.0b2, but I have a patch on SF to do that:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470


> (b) allow every version of Python to somehow resolve and load the
> correct extension out of several available, based on versions, and

I don't think anything beyond what is there will be provided, IOW, you
already have the means of loading the right version of an extension
module based on the PYTHONPATH. On Unix, put the module in the
version-specific site-packages directory; on Windows, either put it in
the version-specific DLLs directory, or adjust the version-specific
path in the registry.

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

That might work on Unix between 2.0 and 2.1; on Windows, the
python.dll version is coded into the DLL.

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

That would make hand-writing of Python extensions much more difficult,
especially when it comes to new C/Python types. How exactly is
allocation/deallocation working here?

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

That would be fixed with my pending patch - apparently nobody though
of that approach before.

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

The problem with a COM-like approach is that you always have to carry
objects around. I.e. PyString_FromStringAndSize won't work anymore, it
will be

  my_interpreter->string_from_string_and_size("Hallo", 5);

With such a mechanism, you'd indeed get rid of the problem that the
DLL name must be associated with the extension module.

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

I'm quite certain that P3K will have a perfect solution :-)

Regards,
Martin