[Python-Dev] Integrate lxml into the stdlib?

Guido van Rossum guido at python.org
Fri Mar 6 19:25:44 CET 2009


On Fri, Mar 6, 2009 at 9:54 AM, Terry Reedy <tjreedy at 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/)


More information about the Python-Dev mailing list