For the "deleted modules" section of the 2.0 article, I drew up a list of modules that might be outdated, mostly the SGI-specific ones. Are those modules still useful, and do the libraries they were written for still exist? For your cogitation, here's the list: sgimodule.c, glmodule.c (and hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, almodule.c, clmodule.c, knee.py. Also, can someone explain why importing a third party extension built for Python 1.5.x is supposed to result in an immediate crash on Windows? I'd like to explain why this happens... --amk
Also, can someone explain why importing a third party extension built for Python 1.5.x is supposed to result in an immediate crash on Windows? I'd like to explain why this happens...
The 1.5 module is linked against Python15.dll. When Python.exe (linked against Python16.dll) starts up, it initializes the Python data structures in Python16.dll. When Python then imports foo.pyd (linked against Python15.dll), it immediately tries to call the functions in that DLL (such as getting the thread state). As Python has not been initialized in that DLL, we immediately die. Ironically, if Python1x.dll was simply named "Python.dll", there is a _reasonable_ chance it would work fine. The cost of doing this tho, is that you can not have Python 1.5 and Python 1.6 "side by side" on the same machine. There are a few possibilities for magic tricks we could pull, but to be honest Im not too inclined to bother with them myself... They would also require a commitment to a fully backwards compatible C API, which I dont think we can afford to commit to! Mark.
Guido van Rossum
For the "deleted modules" section of the 2.0 article, I drew up a list of modules that might be outdated, mostly the SGI-specific ones. Are those modules still useful, and do the libraries they were written for still exist?
Doubtful. I've asked Sjoerd and Jack, who were most involved in using these.
For your cogitation, here's the list: sgimodule.c, glmodule.c (and hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, almodule.c, clmodule.c, knee.py.
I'd like to keep knee.py -- it's a nice piece of *documentation* of the package import.
+1 on giving the SGI-specific modules the heave-ho. Their presence has always struck me as a sort of vermiform appendix in a core library otherwise clearly aimed at being as platform-independent as rdeasonably possible (e.g. given the Unix-vs.Windows differences). -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Power concedes nothing without a demand. It never did, and it never will. Find out just what people will submit to, and you have found out the exact amount of injustice and wrong which will be imposed upon them; and these will continue until they are resisted with either words or blows, or with both. The limits of tyrants are prescribed by the endurance of those whom they oppress. -- Frederick Douglass, August 4, 1857
For the "deleted modules" section of the 2.0 article, I drew up a list of modules that might be outdated, mostly the SGI-specific ones. Are those modules still useful, and do the libraries they were written for still exist?
Doubtful. I've asked Sjoerd and Jack, who were most involved in using these.
For your cogitation, here's the list: sgimodule.c, glmodule.c (and hence cgenmodule.c), imgfile.c, svmodule.c, flmodule.c, fmmodule.c, almodule.c, clmodule.c, knee.py.
I'd like to keep knee.py -- it's a nice piece of *documentation* of the package import. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Andrew Kuchling -
Eric S. Raymond -
Guido van Rossum -
Mark Hammond