[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?

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