On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard
<steven.beth...@gmail.com> wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <i...@colorstudy.com> wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>> <steven.beth...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
