BTW: This is fact is not off-topic at all - we are discussing
evolving the stdlib and Jesse brought up the idea of breaking up the
stdlib as answer to the discussions we had about getopt/optparse/
argparse.
This thread then shifted into a different direction:
that of breaking up the stdlib to make life easier for other
Python implementations than CPython.
This was the driving force - the discussions about deprecating and
evolving stdlib came later. But yes, we are talking about a lot of
orthogonal issues
.
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.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
