From: "Martin v. Loewis" <martin@v.loewis.de>
Guido van Rossum <guido@python.org> writes:
If you find that a "good" redesign requires a shared libpython, then so be it - but I'm still quite fond of the "single executable" appraoch, so preserving that would be even better.
Why? I thought there was serious work underway to make libpython.so a reality on Linux?
It already is, with --enable-shared.
...interesting...
However, I still think that people creating --enable-shared installations are misguided: You gain nothing
On AIX, you'd gain at least a little something: there would be no need to "manually" patch up the symbol references the way _PyImport_LoadDynamicModule is currently doing, and shared libraries that were not themselves extension modules wouldn't have to duplicate that functionality (as I understand you are saying they should in lieu of hijacking the Python call). Whether that makes the separate shared library worth it or not, I can't say. Probably not in light of the other benefits you list here. The AIX problem with resolving symbols from an executable is strange enough that it can be a significant obstacle to porting systems built around Python. The only way we figured it out was by crawling through the Python source to figure out how the symbols were getting resolved. It would be really nice if there were a "documented and stable" version of the core functionality which is doing the symbol patching. Since Python is an executable which expects to share its symbols with libraries, it's not unreasonable to think that Python ought to provide the means to do it. Coming up with a code patch wouldn't be too hard, I think, but where would the documentation go? -Dave