Orestis Markou wrote:
[snip...]
And that discussion then led back to the original discussion
about how to evolve the stdlib, since it included deprecation
of modules, which then resulted in my summary of the situation
w/r to the parsing libs.
The two threads "should we try to add argparse?" and
"Breaking out the stdlib" both target the same basic
topic: How much change is needed and wanted in the stdlib ?
Part of the answer involves looking at the maturity of new
code vs. that of the existing code and weighing added
features vs. breaking backwards compatibility.
So to correct my summary: argparse has been stable for 2 years,
optparse for 7 years, getopt for >9 years (the last major
change was in 1998).
Anyway, Frank is going to write a PEP covering splitting the
stdlib into chunks in order to simplify reuse in Jython,
IronPython, etc. so that's a good result.
Just to avoid any misunderstandings: I don't have anything
against argparse or adding it to the stdlib.
I'm only concerned about the effects of deprecating modules
that are in wide-spread use, in this case getopt and optparse,
without providing a drop-in API compatible replacement.
A deprecated -> removed module can always exist in PyPI and manually
installed (or perhaps they can live in their own special place
stdlib-legacy). When a new version of Python comes out, people *do*
have to spend some time testing their apps, so if something has moved
from stdlib to stdlib-legacy, they can just install that in their site
packages and go on pretending nothing happened.
For me, deprecating modules and adding new ones is more of a social
move - it shows that the Python community cares, and it moves Python
closer to the bleeding edge. I think it can be done without alienating
legacy users.
I don't think it is a goal for the standard library to be bleeding edge.
We definitely allow other libraries to be bleeding edge and then steal
them for the standard library once they have proven widely used, stable
and best-of-breed.
Part of the problem is that there are a lot of 'legacy' modules in the
standard library that don't meet these criteria by a long way. Removing
those is one issue that Jesse is about to embark on addressing with a PEP.
I also disagree with those who think that having a stable standard
library means having a genuinely dead standard library. If I have time
I'll compose a response to that - but I don't think that is *possible*
(unless we also stop improving Python the language) or desirable
socially or technologically.
Michael
Thanks,
--
Marc-Andre Lemburg
eGenix.com
_______________________________________________
stdlib-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/stdlib-sig
--
http://www.ironpythoninaction.com/
_______________________________________________
stdlib-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/stdlib-sig
