On 27Sep2009 21:24, Steven Bethard <steven.bethard at gmail.com> wrote: | On Sun, Sep 27, 2009 at 9:09 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote: | >> If you think getopt and optparse should stick around in 3.X, why is | >> that? If you think there are things that getopt and optparse do better | >> than argparse, could you please give some examples? | > | > I personally consider getopt superior to both optparse and argparse. | > Those are terribly verbose in specifying arguments, whereas getopt's | > sequence-of-letters is really nice and compact. | | Thanks for the concrete example. Although I'm unconvinced that the | characters you save in the sequence of letters in the getopt.getopt | call aren't afterwards wasted on type conversions, if/else statements | and variable assignments in the subsequent loop, it would be pretty | simple to add to argparse something like:: | | ArgumentParser.add_getopt_arguments(options[, long_options]) Yes please! I'm also very fond of the succinct getopt sequence-of-letters style; it works really well for the simple cases. Disclaimer: I've not used the optparse et al modules because getopt has covered my needs and my C background made getopt the natural module to start with. I have written simple getopt-equivalent option parsers a number of times though. (Of course, that choice also drives me to adapt my option wishes to stuff that getopt can do:-) Clarification: this isn't a vote for preferring getopt, it's a vote for availability of the sequence-of-letters style. Cheers, -- Cameron Simpson <cs at zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ The most annoying thing about being without my files after our disc crash was discovering once again how widespread BLINK was on the web.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4