[stdlib-sig] should we try to add argparse?

Yuvgoog Greenle 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.

--MrPyopt


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
>> module.
>>
>> 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
> ongoing.
>
> As Brett says, even if we go down this road, optparse won't actually be
> removed for several years.
>
> Michael
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>



-- 
Yuv
http://code.google.com/p/pyopt/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20090911/e6f42064/attachment-0001.htm>


More information about the stdlib-sig mailing list