[Python-Dev] buildin vs. shared modules
Shane Holloway (IEEE)
shane.holloway at ieee.org
Fri Oct 17 14:35:41 EDT 2003
Thomas Heller wrote:
> Here is the list of Python 2.3 extension modules, in decreasing order of
> my preference to be converted into a builtin.
> Needed to start Python - should be builtin:
> zlib _sre
+1 -- would not these speed startup time?
> Used by myself everyday - would like them to be builtin:
> _socket _winreg mmap select
+0 -- I use them a lot, but the overhead importing them is definitely
acceptable to me.
> I'm undecided on these modules, I do not use them now but may in the
> future - so I'm undecided:
> _csv winsound datetime bz2
-0 -- Useful modules, but not on my everyday use list.
> These should remain in separate pyd files for varous reasons:
> _tkinter _bsddb _testcapi pyexpat
Definitely agreed. :)
> Don't know what these do, so I cannot really comment:
> _symtable parser unicodedata
Neither do I. Although unicodedata is fairly big.
> And while we're at it, I have looked at sys.builtin_module_names (again,
> from Python 2.3), and wondered if there arn't too many.
> I have *never* used any of these (xxsubtype is only a source code
> example, isn't it):
> audioop imageop rgbimg xxsubtype
+1 -- I agree that these would not suffer too badly from being external
> and I guess some of these could also be moved out of python.dll (rotor
> is even deprecated):
> _hotshot cmath rotor sha md5 xreadlines
+1 for _hotshot, rotor, and xreadlines -- External would be good.
-0 for sha, md5 -- I like these the way they are, but I see your point.
-1 for cmath -- complex types are part of the language, and should be
> There may be incompatibilities - that's why I asked about 2.3.3 or 2.4.
-1 for 2.3.3 or any point release in 2.3
+1 for 2.4
> The biggest problem would probably be that you would have to download
> additional sources - zlib is one example.
> Who cares about the python.dll file getting larger? As Martin explained,
> this shouldn't increase memory usage, and since zlib and _sre are loaded
> anyway at Python starup, the startup time should decrease IMO.
Small is beautiful. Fast is good. I don't like the idea of statically
linking pyds into python simply because we can. Nor does reducing the
number of external files for packagers like py2exe. I know that pain
too, but I don't want python to suffer from too much bloat for that reason.
> Let me conclude that I have no pressing need for changing this, but the
> decision whether an extension module is builtin or in a dll should
> follow a certain pattern.
> To reduce the number of files py2exe (or installer) produces the best
> way would be to build custom python dlls containing the most popular
> extensions as builtins. Of course this can be done by everyone owning a
> C compiler and a text editor. And my own version would certainly
> include _ctypes ;-)
I love ctypes :) It saves me from doing hard work ;)
Thanks for reading :)
More information about the Python-Dev