On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Keeping getopt around *and* including a "add_getopt_arguments" method in
> argparse is probably the best of both worlds, in that it allows for
> relatively straightforward evolution of an application:
>
> 1. Start with getopt
> 2. As the getopt argument parsing gets twisty and arcane and maintaining
> the help string becomes a nightmare, move to argparse with the
> "add_getopt_arguments" method.
> 3. Over time, convert more arguments to proper argparse arguments with
> full documentation.
One thing that wouldn't be good in this transition is that
"add_getopt_arguments" can only generate the part of the help string
that says "-a" and "--author" exist as options -- it can't add the
additional bit of text that says what they do because that's not
provided to the getopt API.
I suspect this makes the transition less convenient because with
getopt you were probably already manually maintaining a usage message
that had at least some of this information, and switching to
"add_getopt_arguments" would mean throwing this information away.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
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