[Python-Dev] Pronouncement on PEP 389: argparse?
Terry Reedy
tjreedy at udel.edu
Mon Dec 14 20:48:53 CET 2009
On 12/14/2009 1:43 PM, Steven Bethard wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking<ianb at colorstudy.com> wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>> <steven.bethard at gmail.com> wrote:
>>> So there wasn't really any more feedback on the last post of the
>>> argparse PEP other than a typo fix and another +1.
>>
>> I just converted a script over to argparse. It seems nice enough, I
>> was doing a two-level command, and it was quite handy for that.
>>
>> One concern I had is that the naming seems at times trivially
>> different than optparse, just because "opt" or "option" is replaced by
>> "arg" or "argument". So .add_option becomes .add_argument, and
>> OptionParser becomes ArgumentParser. This seems unnecessary to me,
>> and it make converting the application harder than it had to be. It
>> wasn't hard, but it could have been really easy. There are a couple
>> other details like this that I think are worth resolving if argparse
>> really is supposed to replace optparse.
>
> Thanks for the feedback. Could you comment further on exactly what
> would be sufficient? It would be easy, for example, to add a subclass
> of ArgumentParser called OptionParser that has an add_option method.
> Do you also need the following things to work?
[snip]
I have not ever used optparse. So if I were to use argparse in the
future, I would strongly prefer that it be free of back-compatibility cruft.
Would it be possible to use the 2to3 machinery to write an opt_to_arg
conversion tool? This could easily take care of the naming differences.
Terry Jan Reedy
More information about the Python-Dev
mailing list