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

[Brett Cannon]

On Thu, Sep 10, 2009 at 14:58, Yuvgoog Greenle <ubershmekel at gmail.com> wrote:
> +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.

If this moves forward there will be a PEP and you can bring this idea up then.

-Brett

> --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/
>
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>
>