[Python-Dev] Pronouncement on PEP 389: argparse?

Ian Bicking ianb at colorstudy.com
Mon Dec 14 20:04:03 CET 2009


On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard
<steven.bethard at gmail.com> 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?

Well, to argue against myself: having another class like OptionParser
also feels like backward compatibility cruft.  argparse is close
enough to optparse (which is good) that I just wish it was a bit
closer.

> * options, args = parser.parse_args() # options and args aren't
> separate in argparse

This is a substantive enough difference that I don't really mind it,
though if OptionParser really was a different class then maybe
parse_args should act the same as optparse.OptionParser.  What happens
if you have positional arguments, but haven't declared any such
arguments with .add_argument?  Does it just result in an error?  I
suppose it must.

> * type='int', etc. # string type names aren't used in argparse

This seems simple to support and unambiguous, so yeah.

> * action='store_false' default value is None # it's True in argparse

I don't personally care about this; I agree the None default in
optparse is sometimes peculiar (also for action='count' and
action='append', where 0 and [] are the sensible defaults).

Also I'd like %prog and %default supported, which should be fairly
simple; heck, you could just do something like usage.replace('%prog',
'%(prog)s') before substitution.  Since %prog isn't otherwise valid
(unless it was %%prog, which seems unlikely?) this seems easy.


Ideally I really wish ArgumentParser was just named OptionParser, and
that .add_argument was .add_option, and that argparse's current
parse_args was named something different, so both the optparse
parse_args (which returns (options, args)) and argparse's different
parse_args return value could coexist.  Also generally if the common
small bits of optparse (like type='int' and %prog) just worked, even
if they weren't really extensible in the same manner as optparse.

Another thing I just noticed is that argparse using -v for version
where optparse does not (it only adds --version); most of my scripts
that use -v to mean --verbose, causing problems.  Since this is a poll
question on the argparse site I assume this is an outstanding question
for argparse, but just generally I think that doing things the same
way as optparse should be preferred when at all reasonable.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker


More information about the Python-Dev mailing list