Python option parsing

Dusty · 2006-09-17 19:33:58

Hey all,

Does anyone know of an easy way to make optparse.OptionParser not fail if it comes across an option it doesn't know about? What about getopt.getopt?

I'm trying to decide the best way to pass options to plugins for Pallavi. The simplest way seems to be to allow each plugin to parse sys.argv independently. But to do this, it needs to be able to ignore options that are of interest to other plugins or the core. And so far, I can't seem to make OptionParser ignore those options.

The other way I could implement this is to collect the relevant options from each plugin before loading them, but this seems overkill and java-esque. It wouldn't be hard, just inelegant. The worst part is I need to parse at least one option before the plugins are loaded, and I hate special cases.

Basically, I don't want this error:

>>> from optparse import OptionParser
>>> parser = OptionParser()
>>> o = parser.add_option("-c")
>>> parser.parse_args(["-c", "config", "-m"])
usage: [options]
: error: no such option: -m

Thanks for any insight,
Dusty

T-Dawg · 2006-09-17 20:35:55

I used getopt and put everything in try: except:. The exception is someting like getopt.GetoptError or something like that. Look at top half of aurbuild.

Dusty · 2006-09-17 20:38:04

But will that parse all the options? I basically want to get all the relevant options and ignore the others. I've realized this is a lot more difficult than it sounds because you need to know if an argument following an option is associated with that option or its a positional argument. I think I'll have to go with a whole messy system, or else ignore it altogether. :-(

Dusty

T-Dawg · 2006-09-17 20:55:19

getopt keeps track of which arg goes to which opt. Its something like

opts, args = getopt.getopt(bla bla)
for opt, optarg in opts:
     if opt in ['-y', '--yourswitch']: switch1='set'; switcharg=optarg

Dusty · 2006-09-17 21:11:33

Yeah, I know all about that. My problem is a little less trivial. (BTW: you might want to look at optparse instead of getopt, it handles a lot of the ugly crap for you)

It would look somehting like this: Basically, I have a list of command line arguments. I want to parse them in two or more different plugins. One plugin will use some arguments, and one plugin will use the other arguments, and some arugments may be for a plugin that's not loaded. The plugins don't communicate. My plan was to take sys.argv in each plugin and let it parse out only those options it knows and cares about, ignoring any others. So ideally I could use getopt in each plugin and just parse the options it likes, ignoring the others. However, getopt chokes as soon as it discovers an option it hasn't been made aware of. Therein lies my problem.

but since it is conceivable that some options will have arguments and some will not, I think I may have to make a single option parser that is aware of all plugins. And that's gonna be slightly inelegant.

Dusty

cmp · 2006-09-17 21:13:02

you may subclass optparse.OptionParser. but it seems kinda hard

Dusty · 2006-09-17 21:23:53

cmp wrote:

you may subclass optparse.OptionParser. but it seems kinda hard

Yeah, I had a look at that. I'm thinking maybe I'll attack the problem differently for now. Apparently its not as easy as it should sound.

Dusty

nogoma · 2006-09-18 00:17:44

(Ok, so this is from my experience with Ruby's OptionParser, so sorry if this is just noise in terms of the Python version.)
I had a similar problem, so here's what I did. First, my actual situation is I had a piece of code that had an "action" option, and each action took sub-options, which were specific to the action. i.e. you'd invoke my script like:

$ foo.rb --bar --verbose --widget

Where "verbose" and "widget" were options of the "bar" action...
My solution was to create my options object (call it opts), set the options (opts.on("-v", ...)), then collect the valid flags (both long and short version) from the options object (some stuff here that I imagine is pretty ruby-specific, hopefully its fairly obvious how to do this from the python object...). I then split ARGV into two arrays: one containing those strings that match the arguments the opts object takes (call this main_args), and everthing else (call this sub_args). So, for my example above:

main_args # => ["--bar"]
sub_args # => ["--verbose", "--widget"]

Then I call opts.parse(main_args) (i.e. this opts object will never see those flags it doesn't understand), use that to determine which action to take (which actually creates an Action subobject), then pass sub_args to my Action subobject, which holds its own OptionParser object that knows how to parse *those* arguments. HOWEVER, it's really unpleasant if some of the options of your main OptionParser takes arguments; I made sure all the main options were binary switches. Anyway, I hope that makes sense, and maybe suggests a solution to you when doing it in Python. My original inclination was to roll my own solution for this sort of problem, but dealing with all the cases of option parsing is... unpleasant . This is definitely a case where letting other's people code work for you is a huge benefit, IMO. I guess it's a choice between having to contort yourself to OptionParser's demands, and rolling your own.

cactus · 2006-09-18 01:29:12

Dusty. I think excessive command line options is the wrong path to go here.

Something like the ability for a plugin to parse, or have preparsed and just pass the data to the plugin, custom sections of a shared configuration file. That seems like more reasonable solution than trying to determine on the fly if certain command line options are valid or not.

Dusty · 2006-09-18 01:52:40

cactus wrote:

Dusty. I think excessive command line options is the wrong path to go here.

I agree. If there were going to be a lot of options, I would simply implement a full-fledged cross-plugin parser.

Something like the ability for a plugin to parse, or have preparsed and just pass the data to the plugin, custom sections of a shared configuration file. That seems like more reasonable solution than trying to determine on the fly if certain command line options are valid or not.

I already have the shared config file implemented. The command line options are for 'one-time' type things, or mutually exclusive things.

Dusty

Arch Linux

#1 2006-09-17 19:33:58

Python option parsing

#2 2006-09-17 20:35:55

Re: Python option parsing

#3 2006-09-17 20:38:04

Re: Python option parsing

#4 2006-09-17 20:55:19

Re: Python option parsing

#5 2006-09-17 21:11:33

Re: Python option parsing

#6 2006-09-17 21:13:02

Re: Python option parsing

#7 2006-09-17 21:23:53

Re: Python option parsing

#8 2006-09-18 00:17:44

Re: Python option parsing

#9 2006-09-18 01:29:12

Re: Python option parsing

#10 2006-09-18 01:52:40

Re: Python option parsing

Board footer