> snuck a peek at the newly included optparse module yesterday and it seems
> option parsing will be a breeze in the future. good work!
>> however, imho, it seems a bit too focused on initial sys.argv parsing.
> for anything else, you basically have to subclass OptionParser etc to do
> anything useful.
>> for example, you can supply your own argument list to the parse_args()
> method, but the autohelp/version/error reporters still use sys.argv[0] as
> command name (probably not what you want). the way optparse gets the
> command name (a global function) indicates that you're not supposed to
> override it?
>> also, even if you tell OptionParser to use your user defined Option class
> (as explained in the docs: op = OptionParser(option_class=MyOption)), it
> still adds standard Option instances to handle autohelp/version.
>> per default, the autohelp/version/error handlers call sys.exit(). the
> docs says that if you want to change this behaviour, simply subclass
> OptionParser and/or Option and override/extend the corresponding methods.
> ofcourse, this has no effect, since standard instances are used.
>> also, supressing the actual printing of autohelp/version/error requires
> subclassing OptionParser and Option (or sys.stdout = StringIO fiddling).
>> so? some minor glitches and (imho) annoyances, whats the deal?
>> well, to me, it's pretty obvious that the design effort on optparse has
> pretty much been focused strictly on initial sys.argv parsing and while
> it's extendable, other use cases (embedded consoles etc) seem to have been
> given little or no real thought.
>> the things i mention is probably easy to fix:
>> * make parse_args() take the whole "sys.argv" list and use the first
> element as the command name. breaks backward compatibility, i know.
> why was sys.argv[1:] used in the first place? the getopt legacy?
>> * add parse_args_ex() that raises an exception containing the help/error
> message instead of SystemExit (SystemExit containing something means
> something went wrong, don't it?)
>> * (simple bug) dynamically populate the OptionParser using the
> option_class and not some pre-made Option.
>> * (simple bug) replace all %prog in help texts etc, not just the first
> occurance.
You make some good points.
A patch uploaded to SF would be welcome.
--Guido van Rossum (home page: http://www.python.org/~guido/)
