optparse question

[GMTaglia]

Hi guys,

I was wondering why optparse accept an option if in the command line is not
*exactly* the one present in the source code....may be an example will
explain better....

#!/usr/bin/env python

import optparse as opt

parser = opt.OptionParser()
parser.add_option("-f", "--filein", dest="fileinput", help="filename to
read", metavar="FILE")
(options, args) = parser.parse_args()
count = 0
filename = open(options.fileinput, 'r')
for lines in filename.xreadlines():
count += 1
print count

if you run this dumb example in this way:

liquid@jupiter liquid $ ./testi.py --fil elenco_tm.txt
367

it goes on, but the option must be --filein not --fil

Is true that if you have another option like

parser.add_option("-f", "--fileout", dest="fileoutput", help="filename to
write", metavar="FILE")

the program will stop raising a conflict option, but why accept only the
beginning of the long option instead of the exact one?

Have a nice sunday, and as usual sorry for the english...
GMario

[George Yoshida]

GMTaglia wrote:

Hi guys,

I was wondering why optparse accept an option if in the command line is not
*exactly* the one present in the source code....may be an example will
explain better....

#!/usr/bin/env python

import optparse as opt

parser = opt.OptionParser()
parser.add_option("-f", "--filein", dest="fileinput", help="filename to
read", metavar="FILE")
(options, args) = parser.parse_args()
count = 0
filename = open(options.fileinput, 'r')
for lines in filename.xreadlines():
count += 1
print count

if you run this dumb example in this way:

liquid@jupiter liquid $ ./testi.py --fil elenco_tm.txt
367

it goes on, but the option must be --filein not --fil

Is true that if you have another option like

parser.add_option("-f", "--fileout", dest="fileoutput", help="filename to
write", metavar="FILE")

the program will stop raising a conflict option, but why accept only the
beginning of the long option instead of the exact one?

I encountered the same question, looked at the source and found
the answer.

Quote from the document of getopt module:
http://docs.python.org/lib/module-getopt.html

Long options on the command line can be recognized so long as they
provide a prefix of the option name that matches exactly one of
the accepted options. For example, it long_options is ['foo',
'frob'], the option --fo will match as --foo, but --f will not
match uniquely, so GetoptError will be raised.

optparse is same as getopt in this respect.

George

[GMTaglia]

George Yoshida wrote:

optparse is same as getopt in this respect.
that's fine but....why?

I think it will be better if only the *exact* option will match, it will
avoid typing mistakes and/or accidentally wrong matches, imho.

George

ciao
GMario

[George Yoshida]

GMTaglia wrote:

I think it will be better if only the *exact* option will match, it will
avoid typing mistakes and/or accidentally wrong matches, imho.

I think this is because getopt module is designed as a pure Python
implementation of Unix(Linux?) getopt function.

I tested the sample code in C and it handled long options as
Python does.

George

[Peter Otten]

GMTaglia wrote:

I think it will be better if only the exact option will match, it will
avoid typing mistakes and/or accidentally wrong matches, imho.

The source is there to override, even if it scares you away with abundant
underscores.

import optparse

def _(s): return s

class OptionParser(optparse.OptionParser):
def _match_long_opt(self, opt):
if opt in self._long_opt:
return opt
raise optparse.BadOptionError(_("no such option: %s") % opt)

if __name__ == "__main__":
p = OptionParser()
p.add_option("--long", action="store_true")
options, args = p.parse_args()
print "long:", options.long

Peter

[Thorsten Kampe]

* GMTaglia (2004-09-18 23:39 +0200)

George Yoshida wrote:

optparse is same as getopt in this respect.
that's fine but....why?

To avoid unneccesary typing when the typed option is unambiguous. It's
the same with [y]es and [n]o. It makes things faster but increases
typo mistakes.
I think it will be better if only the *exact* option will match, it will
avoid typing mistakes and/or accidentally wrong matches, imho.

It won't avoid them but it will make them less likely. On the other
hand you could disable short options and make your long options at
least fifteen characters long to avoid typing mistakes and accidental
wrong matches.

*I* myself always use the complete long option when I use one but
maybe your users will find typing only a part comfortable?

On the other hand: if you have a lot of similar options, consider
renaming them so that they start with a different character or use a
config file (ConfigParser). May gpg be your guiding nightmare.

Thorsten