Unicode + SuperUltraAllNewGetItNow Python Upgrade questions: ASP/VBScript->Python

[David Bolen]

"Alex Martelli" <aleaxit at yahoo.com> writes:

>                                                , but foo.pyd files
> will generally break.  On Windows, the breakage is truly painful:
> it crashes the Python interpreter when a script tries to import
> a module that exists as a .pyd built for another version... alas,
> this is the default way Windows' DLL's work, and a .pyd is just a
> .DLL with a different extension for clarity.  It would slow down
> Python's "import" statement substantially, I think, if it had to
> carefully check before loading the .pyd (although it *might* be
> nice to have some flag on the Python interpreter to have it run
> in a "paranoid mode", to be used when one has just upgraded and
> may not have rebuilt everything...).

I never really figured this problem out - I know there was an immense
amount of discussion on python-dev, and while I can understand the
difficulty in trying to come up with a general model for cross-version
compatibility and identification, I don't see why the crash couldn't
be avoided.

If trying to load the 1.5.2 extension under 1.6/2.0 is not going to
work, why couldn't Python have establish a new export symbol for
1.6/2.0 extensions that Python can look for during the import (very
low overhead) and refuse to call the init* function in the extension
if not present.

True, that's not a clean way to try to support various cross-version
compatibilities, but a crash is pretty horrendous to leave in place
given that you aren't getting the compatibility anyway.

--
-- 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     \
\-----------------------------------------------------------------------/