R. David Murray wrote:
On Tue, 15 Sep 2009 at 12:53, Michael Foord wrote:
There seem to be three positions:
1) Virtually no changes or improvements to the standard library at
all - nothing beyond maintaining compatibility with language changes.
(Laura)
I think you misrepresent Laura's opinion. She wants modules that
are mature (stable) to remain in the library, but I did not hear her
object to the addition of improvements. (She said perhaps she should
have objected to optparse, but that was a hypothetical conditioned on
getopt being removed...if getopt remains (as she expected it would)
she had/has no objection to optparse (or, presumably, argparse)).
It's a caricature - but hard to express in a single line. ;-)
Her explicit preference however is for a standard library that is
"dead-as-a doornail whenever possible" and that I think is something
that is actively against what many of the core developers are working for.
2) New modules are acceptable but old modules should remain forever.
(Antoine)
3) New modules are acceptable and eventual removal of old modules is
desirable. (Brett, myself, Jesse and Frank)
Laura's objection was to this label of "old modules", as if all modules
beyond a certain age were automatically bad and should be removed.
That's a complete mis-characterisation. No one has said modules should
be removed just because they are old. Modules that are unable to evolve
to meet requirements because of API design are a problem though. Merely
because a library meets *some* use cases doesn't make it *good*.
There is also the related issue of what to do about duplicate
functionality - particularly in the case of argparse and optparse where
argparse will completely 'replace' the functionality of optparse and
no-one advocating for keeping it is also willing to maintain it.
There is an important distinction to be made between "old, broken,
and not maintained", and "old, mature, and functional".
Marc-Andre seems to fall somewhere between 1 and 2 and Orestis wants
the bleeding edge. (Sorry for these caricatures but it seems
approximately right.)
I'd still like to write a longer piece on why I think 1) isn't
possible and 3) is preferable to 2) - but the basic points have all
been covered in this thread anyway.
Is anyone actually advocating (1)? I doubt it.
I think Laura's post was excellent and is worth a careful (re)reading to
understand her points.
I think I understand her points and her motivation (and have sympathy
for them), I just don't think they are really feasible (at face value)
for a developing language. I think if you have a hard requirement for
absolute stability then due to language changes alone you will have to
stick to a specific version of Python.
Michael
--David
--
http://www.ironpythoninaction.com/
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
