On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
>> * Would you like argparse to grow an add_getopt_arguments method (as
>> in my other post)?
>
> 0
>
>> * If argparse grew an add_getopt_arguments, would you still want to
>> keep getopt around? And if so, why?
>
> Simplicity of the learning curve. Using it is as simple as:
>
> getopt.getopt(sys.argv[1:], "a:b", ["alpha=", "beta"])
You forgot the for-loop, nested if/else statements and type conversions. ;-)
> Does argparse allow anything as simple as that?
If you mean, does argparse allow configuration to be specified using
the getopt style ("a:b", ["alpha=", "beta"]), no, it currently
doesn't. But if this is useful functionality, and would reasonably
replace the getopt use cases, then I'd be happy to add it. In the
simplest version, we might add something like::
options, args = argparse.getopt("a:b", ["alpha=", "beta"])
where you could then use "options" without any looping::
alpha = options.a or options.alpha
beta = options.b or options.beta
But if people still like the traditional getopt loop with nested
if/elses better, then we might as well just keep getopt around and not
add anything to argparse. I'm fine with that too, I just want to make
sure that there isn't an obvious deficiency in argparse that we could
easily fix.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
_______________________________________________
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
