> > 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 the OS. 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. Dave LeBlanc Seattle, WA USA
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