Michael Foord wrote: > M.-A. Lemburg wrote: >>> Can we please not treat "dead/complete" modules as if they have no >>> maintenance burden, or drag down the code base? The reason I avoided >>> that terminology in the first place is that there is no such thing as >>> code with zero cost. >>> >> >> We're not treating them like that. All along we said, there is >> /very little/ maintenance needed. >> >> Besides, changes such as keyword fixes, grammar changes, style >> changes, etc. get applied to all stdlib modules, so these fixes >> don't really count as module-specific maintenance. Most of these >> fixes are done via a script or grep/sed anyway, so the cost per >> module is very small. >> >> You can have a look at the getopt SVN log to get an impression >> of just how much effort it takes to keep that module running. >> >> These are all changes applied to the module over a period of 7 years: >> > > This doesn't begin to cover the whole cost of keeping a library and its > tests in Python.
It was meant a proof for the code being mature and causing low maintenance costs. > There are all the closed issues that someone has had to > look into and respond to. Every time a developer runs all of the Python > tests he pays some cost for every test of every module. Every time > someone packages, distributes or downloads Python they pay some cost for > every byte in Python. Every time someone translates the documentation, > or updates the documentation (which Georg did recently for *every* > module in the standard library) they pay a cost for every language > feature and module they touch - or have to make a conscious decision not > to touch. Right, I didn't say there were no costs, but then how does the above time compare to e.g. fixing two nasty bugs in a newly adopted module ? You can easily spend a day or two trying to track down such bugs. Certainly more than you spend on doing the things you mentioned above for a module that doesn't have all that many issues. > There is also a cost in keeping bad modules in the library (something > that has already been touched on) in user frustration. Nobody forces a user to use a "bad" module (for whatever meaning the user associates with "bad"). That's what so great about Python: there are a gazillion 3rd party modules out there waiting to get used. > There is of > course a cost in removing modules too - documentation and tutorials go > out of date and need changing. There is definitely an inertia in favour > of not removing modules - but there is also a hidden cost in keeping > them. All of this needs to be weighed (carefully). Sure. What I'm trying to say is that keeping a module in the stdlib costs less than removing it - for everyone. I've been maintaining our eGenix mx Series for more than a decade now, so I do know a little about such costs, where to expect them and where not. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 15 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
