Barry Warsaw wrote: > On Sep 29, 2009, at 8:25 PM, Nick Coghlan wrote: > >> getopt is very procedural - you define a minimal amount regarding the >> options you accept, but then do the bulk of the command line processing >> yourself > > Right, and we shouldn't underestimate the cognitive load this imposes. > All those twisty if-conditions are de-facto part of getopt's API. People assess the mental cost differently though - for getopt, they tend to assign the cost to the script they're currently writing, while for optparse/argparse they assign the cost to those two libraries being difficult to learn :) 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. (Note that getting a good help string "for free" is one of the biggest gains I currently find in using optparse over getopt. This is especially so once you start making use of option groups) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
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