M.-A. Lemburg wrote:
Antoine Pitrou wrote:
Hello,
I am neutral on the idea of adding argparse. However, I'm -1 on deprecating
optparse. It is very widely used (tons of scripts use it), and ok for many uses;
deprecating it is totally unhelpful and gratuitous.
You can add me to that camp as well:
+0 on adding argparse
-1 on deprecating wide-used modules such as getopt and optparse
Note that the last -1 only applies to the module APIs, not the
code in those modules.
If argparse provides an API compatibility layer for getopt and
optparse, the original code of getopt and optparse could go
without problem, IMHO, leaving only the mostly empty modules
together with compatibility layers.
OTOH, as discussed on the stdlib SIG list, those two modules
hardly ever require any maintenance, so keeping them as they
are is certainly an option as well.
Although as also discussed on the stdlib-sig there is also a cost to
leaving unmaintained and unneeded modules in the standard library. As we
are 'end-of-lifing' Python 2.X there seems to be little point in going
down the deprecation route (there won't be enough releases to ever get
to module removal) but discussion about the standard library in
situations like this is badly needed for 3.X.
Certainly a slow deprecation procedure, as suggested by Steven, is
warranted.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
