[stdlib-sig] should we try to add argparse?
solipsis at pitrou.net
Fri Sep 11 00:04:32 CEST 2009
> Why doesn't this argument apply to getopt and optparse equally?
Because optparse has been, for years, the de facto standard API for
parsing command-line arguments. It is reasonably Pythonic and flexible,
if perhaps not as sleek and concise as other alternatives.
getopt is much lower-level, archaic, and probably only appeals to people
who are used to the C version of it.
> The language can be stable, but if the entire 3.x series is just a
> series of bugfixes on top of 3.0's stdlib, then that's a poor state of
This is a false dilemma. There is nothing wrong with introducing new
things. Deprecation of old things, however, should be done carefully,
and with two things in mind:
- the interest of users
- our interest as Python developers and maintainers
It seems to me that optparse has been needing little maintenance, so at
least the second reason doesn't apply here. As for the first reason,
since optparse isn't inherently insecure, fragile, platform-specific, or
wildly under-performing, I don't see it being applicable either.
The main reason, as I understand, is to make the big picture clearer for
new users because there's only one advertised way to do it. While it is
very nice for a clean sheet approach, it certainly isn't a consolation
for people who will have to rewrite their recently broken code...
More information about the stdlib-sig