On Tue, Sep 15, 2009 at 12:16 PM, Paul Moore <p.f.moore@gmail.com> wrote:
2009/9/15 M.-A. Lemburg <mal@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. jesse