On Fri, Mar 6, 2009 at 9:54 AM, Terry Reedy <tjre...@udel.edu> wrote: > Stefan Behnel wrote: >> >> Martin v. Löwis wrote: >>>> >>>> I do see the point you are making here. Even if lxml gets mature and >>>> static, that doesn't necessarily apply to the external libraries it >>>> uses. >>>> However, I should note that exactly the same argument also applies to >>>> sqlite3 and gdbm, which, again, are in the stdlib today, with sqlite3 >>>> being >>>> a fairly recent addition. >>> >>> Fortunately, it is possible for users to just replace the sqlite DLL in >>> a Python installation, with no need of recompiling anything. >> >> Interesting. I assume you are referring to Windows here, right? Does that >> "just work" because the DLL is in the same directory?
No, it is expected to "just work" because sqlite3 is (presumably) very careful about backwards compatibility, and because the Windows DLL API (just like the shared library API in Linux and other systems) is designed to allow substitution of newer versions. The linkage requirements are roughly that all entry points into a DLL (or shared library) that are referenced by the caller (in this case the wrapper extension module) are supported in the new version, and have the same signature and semantics. > I have no idea, but my WinXP .../Python30/ install has > > DLLs/_sqlite3.pyd 52K This is the wrapper extension module. > DLLs/sqlite3.dll 557K This is sqlite3 itself. I am presuming that the phrase "replace the sqlite DLL" above refers to this one -- although the same argument actually holds for the .pyd file, which is also a DLL (despite its different extension). > libs/_sqlite3.lib 2K I think this is a summary of the entry points into one of the above DLLs for the benefit of other code wanting to link against it, but I'm not sure. > For whatever reason, most other things do not have all three files. You only see a .pyd and a .dll when there's a Python wrapper extension *and* an underlying 3rd party library. > I do not know whether upgrades (like 3.0.0 to 3.0.1) would clobber other > things added here. It would, but not in a harmful way. >> That would be a nice feature for lxml, too. We could just make the libxml2 >> and libxslt DLLs package data under Windows in that case. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com