[Python-Dev] PEP 389: argparse - new command line parsing module (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed Sep 30 03🔞59 CEST 2009
- Previous message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Next message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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:
- Start with getopt
- 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.
- 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
- Previous message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Next message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]