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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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