[stdlib-sig] should we try to add argparse?
ubershmekel at gmail.com
Thu Sep 10 23:58:53 CEST 2009
+1 for deprecating optparse or at the very least building a timeline for
it's deprecation. Don't say no to progress, just say when.
I just wrote pyopt http://code.google.com/p/pyopt/ because I think exposing
functions to the command line is way too hard.
If Steven Bethard and the argparse community agree, I would really
appreciate a convenience method named "add_function" built into
the ArgumentParser. add_function would automagically read the docstring and
understand what are the arguments for a given function. I'm willing and
motivated to do the work for this. Annotations-type-casting could be awesome
as well, but I'm not greedy enough to ask.
On Fri, Sep 11, 2009 at 12:39 AM, Michael Foord <michael at voidspace.org.uk>wrote:
> M.-A. Lemburg wrote:
>> Michael Foord wrote:
>>> Antoine Pitrou wrote:
>>>> Upfront people need to realize that we might have three argument
>>>>> parsing libraries for a while, but it won't be forever. If we get
>>>>> argparse accepted we would slowly deprecate at least optparse, if not
>>>>> getopt (lat time I tried to ditch getopt for Python 3 some argued that
>>>>> getopt supported stuff optparse didn't),
>>>> +0 on deprecating getopt, -1 on deprecating optparse. Breaking a
>>>> perfectly functional and useful module is stupid.
>>> So we're stuck with inferior technology?
>> If you have the choice between breaking backwards compatibility
>> and downloading other implementations from PyPI, I think backwards
>> compatibility counts more.
>> We've just had a major change in the stdlib for 3.x. Then the 3.0
>> release was ditched due to poor performance. If we now start
>> deprecating widely used modules in 3.2, we're going to lose
>> a major pro argument for using Python: that of a stable eco system
>> to write code for.
>> I don't think we should deprecate any commonly used module (in the
>> 3.x branch) unless there's a clear and documented migration path
>> or -even better- a migration wrapper available for the deprecated
>> The next major round of refactoring will have to wait for
>> Python 4.x.
> Language refactoring can wait for 4.0. Library improvements should be
> As Brett says, even if we go down this road, optparse won't actually be
> removed for several years.
> stdlib-sig mailing list
> stdlib-sig at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the stdlib-sig