M.-A. Lemburg wrote:
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:
This doesn't begin to cover the whole cost of keeping a library and its
tests in Python. 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.
There is also a cost in keeping bad modules in the library (something
that has already been touched on) in user frustration. 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).
Michael
------------------------------------------------------------------------
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.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
