Jesse Noller wrote: > On Tue, Sep 15, 2009 at 12:16 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> 2009/9/15 M.-A. Lemburg <m...@egenix.com>: >>> Laura Creighton wrote: >>>> So what do you think of this proposal? >>> >>> Good write-up and very much to the point. >>> >>> [Executive Summary: >>> Code that hardly needs any changes, because it does what it's meant >>> to do, is good code, not bad code. And it causes only minimal >>> maintenance effort, so it's actually something core developer should >>> welcome rather than fight against.] >>> >>> I'd only change the tag "dead-as-a-doornail" to "complete, proven and >>> stable". Sounds more accurate. >> >> Yes, I like both the summary, and the proposal (that standard library >> code be tagged with details like its status and its maintainer). >> >> I was in the "stdlib needs to evolve" camp, but this has clarified the >> other side of the argument, and changed my mind. >> >> I'm still in favour of new modules being added to the stdlib, and >> existing modules being updated, but I support the idea of stage C >> (dead as a doornail/complete, proven, stable) modules being retained >> indefinitely. I'm not sure what the implications of this position >> would be in the case of argparse vs optparse (optparse doesn't seem to >> be stage C, so maybe removing it in favour of argparse is an option) >> but I like the fact that this proposal gives us terminology on which >> we can base the discussion. >> >> Paul. > > There is no, no such thing as a "dead/complete" module. It does not > exist. Any time there is a grammar change, a new reserved keyword, or > some other functionality change a "dead" module comes back to life and > has to be maintained. > > 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: ------------------------------------------------------------------------ r67572 | georg.brandl | 2008-12-05 10:23:14 +0100 (Fri, 05 Dec 2008) | 2 lines #4458: recognize "-" as an argument, not a malformed option in gnu_getopt(). ------------------------------------------------------------------------ r31261 | akuchling | 2003-02-06 20:52:56 +0100 (Thu, 06 Feb 2003) | 4 lines A few naughty external scripts do 'raise getopt.error, "blah"', and now crash because two arguments are expected. Add a default value to keep those scripts running. ------------------------------------------------------------------------ r27929 | loewis | 2002-08-04 19:22:59 +0200 (Sun, 04 Aug 2002) | 2 lines Add encoding declaration. ------------------------------------------------------------------------ r27780 | jackjansen | 2002-07-26 13:34:49 +0200 (Fri, 26 Jul 2002) | 2 lines Use os.environ.get() in stead of os.getenv() (which is platform-dependent). ------------------------------------------------------------------------ r27645 | tim_one | 2002-07-16 23:35:23 +0200 (Tue, 16 Jul 2002) | 2 lines Whitespace normalization. ------------------------------------------------------------------------ r27095 | montanaro | 2002-06-07 05:26:43 +0200 (Fri, 07 Jun 2002) | 2 lines gnu_getopt should be exported in __all__ ------------------------------------------------------------------------ r27077 | loewis | 2002-06-06 20:14:50 +0200 (Thu, 06 Jun 2002) | 2 lines Use isinstance for the type check, use booleans. ------------------------------------------------------------------------ r27068 | loewis | 2002-06-06 12:58:36 +0200 (Thu, 06 Jun 2002) | 2 lines Patch 473512: add GNU style scanning as gnu_getopt. ------------------------------------------------------------------------ r26191 | tim_one | 2002-04-05 00:55:58 +0200 (Fri, 05 Apr 2002) | 2 lines Convert a pile of obvious "yes/no" functions to return bool. ------------------------------------------------------------------------ r24680 | fdrake | 2001-12-12 07:20:34 +0100 (Wed, 12 Dec 2001) | 3 lines Wrapped a long line. Converted to use "".startswith() to avoid slicing (& temp string creation). ------------------------------------------------------------------------ r18934 | montanaro | 2001-01-21 00:34:12 +0100 (Sun, 21 Jan 2001) | 2 lines more __all__ updates ... The story is similar for optparse, only that the low maintenance mode has started in 2006. -- 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
