[Python-Dev] buildin vs. shared modules
Gregory P. Smith
greg at electricrain.com
Fri Oct 17 03:49:39 EDT 2003
On Thu, Oct 16, 2003 at 09:38:01PM +0200, Thomas Heller wrote:
> > Thomas Heller wrote:
> >> If I look at the file sizes in the DLLs directory, it seems that at
> >> least unicodedata.pyd, _bsddb.pyd, and _ssl.pyd would significantly grow
> >> python23.dll. Is unicodedata.pyd used by the encoding/decoding methods?
> > No, but it is use by SRE, and by unicode methods (.lower, .upper, ...).
> "Martin v. L?wis" <martin at v.loewis.de> writes:
> > I don't see why it matters, though. Adding modules to pythonxy.dll
> > does not increase the memory consumption if the modules are not
> > used. It might decrease the memory consumption in case the modules are
> > used.
> So, would a patch be accepted (for 2.4, I assume there is no way for
> 2.3.3) which made everything builtin except for the following modules:
> _testcapi - not used outside the testsuite
> _tkinter - needs external stuff anyway
> pyexpat - may be replaced by a third party module
> _ssl - needs Python to be built
I really don't like the idea of linking _bsddb.pyd statically into the
main python DLL (or .so on other OSes). It adds significantly to the
size of the python DLL which isn't fair to projects not using BerkeleyDB.
Statically linking any BerkeleyDB version into python on linux (and
presumably bsd and un*x) means that attempts to use more recent pybsddb
modules with an updated version of the BerkeleyDB library built in
don't work properly due to symbol conflicts causing the old library to
be used with the new module code. I don't know if this problem applies
I don't see any good reason to want fewer .pyd files and a monolithic
More information about the Python-Dev