[Python-Dev] buildin vs. shared modules
whisper at oz.net
Fri Oct 17 02:55:31 EDT 2003
> > 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'd rather see an explicit list of the "everything" that you want to
> bundle into the main DLL.
> --Guido van Rossum (home page: http://www.python.org/~guido/)
I have no really good technical reason for this, but it gives me a bad
feeling - it's Windows, ok? ;)
A few things come to mind:
What's the cost of mapping the world (all those entry points) at startup?
You have to rebuild all of the main dll just to do something to one
component. To me, that's maybe the biggest single issue.
Any possiblity of new bugs?
Are app users/programmers going to have a bloat perception? How many of them
really understand that a dll is mapped and not loaded at startup?
IMO, it contradicts the unix way of smaller, compartmentalized is better.
It's not unix we're talking about, but it still makes sense to me, whatever
On the plus side, it does make some debugging easier if you're working on
extension dlls: fewer sources to have to point Vis Studio at.
On a related side note: has anyone done any investigation to determine which
few percentage of the extensions account for 99% of the dll loads? Maybe
there's no such pattern, but experience suggests there probably is and that
subset might be a better candidate than the whole world.
Seattle, WA USA
More information about the Python-Dev