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 to windows. I don't see any good reason to want fewer .pyd files and a monolithic main DLL. Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4