anyone tried to use optparse with something else than sys.argv?
hi 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. erik
You make some good points. A patch uploaded to SF would be welcome. --Guido van Rossum (home page: http://www.python.org/~guido/)
[cc'ing optik-users@lists.sourceforge.net, since this concerns Optik's reincarnation as optparse in the Python standard library] On 10 December 2002, Erik Heneryd said (on python-dev):
snuck a peek at the newly included optparse module yesterday and it seems option parsing will be a breeze in the future. good work!
Thanks!
Guilty as charged. My intention was always to support that kind of stuff, but I've never had occasion to test it myself. Sounds like I carefully hid lots of little bugs in there -- congrats for finding them. ;-)
Since optparse is new to the stdlib as of Python 2.3, backwards compatibility is not a huge concern; anyone switching from Optik to optparse will have to make changes anyways. So this is an option.
why was sys.argv[1:] used in the first place? the getopt legacy?
Gee, good question. I can assure you it had nothing to do with getopt. I think it was because, despite Unix/libc conventions, I don't see the program name as part of the argument list. That's a perfectly valid interpretation, but I failed to allow a clean/obvious way to override argv[0]. Idea: add a keyword arg 'prog' to OptionParser.__init__() that sets self.prog, and then make get_prog_name() a method that returns self.prog or sys.argv[0]. That feels right. The other possibility is to add a 'prog' argument to parse_args(), but I'm not sure offhand what would happen to it (and how it would find its way to down to usage/version strings.) Anyways, thanks for the bug reports. I'll use your message as a to-do list for Optik 1.4.1. Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ Think honk if you're a telepath.
You make some good points. A patch uploaded to SF would be welcome. --Guido van Rossum (home page: http://www.python.org/~guido/)
[cc'ing optik-users@lists.sourceforge.net, since this concerns Optik's reincarnation as optparse in the Python standard library] On 10 December 2002, Erik Heneryd said (on python-dev):
snuck a peek at the newly included optparse module yesterday and it seems option parsing will be a breeze in the future. good work!
Thanks!
Guilty as charged. My intention was always to support that kind of stuff, but I've never had occasion to test it myself. Sounds like I carefully hid lots of little bugs in there -- congrats for finding them. ;-)
Since optparse is new to the stdlib as of Python 2.3, backwards compatibility is not a huge concern; anyone switching from Optik to optparse will have to make changes anyways. So this is an option.
why was sys.argv[1:] used in the first place? the getopt legacy?
Gee, good question. I can assure you it had nothing to do with getopt. I think it was because, despite Unix/libc conventions, I don't see the program name as part of the argument list. That's a perfectly valid interpretation, but I failed to allow a clean/obvious way to override argv[0]. Idea: add a keyword arg 'prog' to OptionParser.__init__() that sets self.prog, and then make get_prog_name() a method that returns self.prog or sys.argv[0]. That feels right. The other possibility is to add a 'prog' argument to parse_args(), but I'm not sure offhand what would happen to it (and how it would find its way to down to usage/version strings.) Anyways, thanks for the bug reports. I'll use your message as a to-do list for Optik 1.4.1. Greg -- Greg Ward <gward@python.net> http://www.gerg.ca/ Think honk if you're a telepath.
participants (3)
-
Erik Heneryd -
Greg Ward -
Guido van Rossum