[Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python

James C. Ahlstrom jim@interet.com
Thu, 13 Jul 2000 14:34:03 -0400

Mark Hammond wrote:

> Yes, and each of these versions has broken various programs.  Of all
> people, Im surprised to see you falling for the MS hype, Jim.

My experience is that it often works.  I have also (who hasn't?) had
the experience that mysterious bugs disappear by installing the
newest DLLs.

> > What this means is that if the new Python 2.0 (1.6?) simply names
> > its DLL python15.dll just as before, everything Just Works almost.
> > That is, it Just Works provided that foo.pyd only calls Python
> > C functions whose interface has not changed.
> IMO, this constrains us too much.  We can't afford this - we simply dont
> have the resources.

I guess I haven't made myself clear.  I am not proposing
that we freeze the C interface.  I am not proposing that we
scrutinize any *.pyd's for incompatabilities.

I am proposing that we leave the "python15.dll" name the same.
I am proposing that the various *.pyd authors themselves either
provide newer versions, or declare that their *.pyd needs no
newer version of python15.dll.

It is a matter of odds.  If we necessarily rename python15.dll
for each version release, Python has a 100% chance of failing
with an obscure error or crashing if it uses any *.pyd at all
unless all *.pyd are replaced with new versions.

If we do not rename python15.dll, then a *.pyd may or may not
fail.  My guess (only a guess) is that many will work OK.

> > You can support Python 1.5 and 1.6 by removing the python*.dll
> > from the Windows directories, and putting it in the directory
> > of python.exe so it goes with the proper executable.
> We have discussed this over and over and over, ad nauseum.  If you believe
> the earlier discussions were bunk, please refute them.  Otherwise, simply
> re-asserting something that we have previously proven to be incorrect
> doesnt help anyone.

Putting python15.dll in with python.exe works fine for just
using the interpreter python.exe, and it works fine for Python
extensions.  It fails when the client for python15.dll is not
python.exe, but is some other client such as COM.  That is, it
fails to support Python embedding in general.

I proposed that someone who needed multiple Python versions
could use this solution provided that he/she had no use for
embedding.  Not as a general policy.

> > Yes, and this is a major problem, and is un-Windows-like.
> :-)  "Major Crashes" are un-Windows like?  What is happening to this
> group - It amusing that this statement could be made without the Linux
> geeks making smart-arsed comments :-)  Looks like Billy Boy really _is_
> taking over the world :-)

I am a Linux geek myself.  And Windows is more and more
stable all the time.  And yes, Bill is taking over the world
and I doubt DoJ can stop him.