getopt with negative numbers?

[Casey]

Is there an easy way to use getopt and still allow negative numbers as
args? I can easily write a workaround (pre-process the tail end of
the arguments, stripping off any non-options including negative
numbers into a separate sequence and ignore the (now empty) args list
returned by getopt, but it would seem this is such a common
requirement that there would be an option to treat a negative value as
an argument. Note that this is only a problem if the first non-option
is a negative value, since getopt stops processing options as soon as
it identifies the first argument value.

Alternatively, does optparse handle this? I haven't used optparse (I
know it is more powerful and OO, but you tend to stick with what you
know, especially when it is part of my normal python programming
template), but if it handles negative numbers I'm willing to learn it.

 

[Peter Otten]

Is there an easy way to use getopt and still allow negative numbers as
args? I can easily write a workaround (pre-process the tail end of
the arguments, stripping off any non-options including negative
numbers into a separate sequence and ignore the (now empty) args list
returned by getopt, but it would seem this is such a common
requirement that there would be an option to treat a negative value as
an argument. Note that this is only a problem if the first non-option
is a negative value, since getopt stops processing options as soon as
it identifies the first argument value.

Alternatively, does optparse handle this? I haven't used optparse (I
know it is more powerful and OO, but you tend to stick with what you
know, especially when it is part of my normal python programming
template), but if it handles negative numbers I'm willing to learn it.

optparse can handle options with a negative int value; "--" can be used to
signal that no more options will follow:

import optparse
parser = optparse.OptionParser()
parser.add_option("-a", type="int")

options, args = parser.parse_args(["-a", "-42", "--", "-123"])
options.a -42
args

['-123']

Without the "--" arg you will get an error:

parser.parse_args(["-123"])

Usage: [options]

: error: no such option: -1
$

Peter

 

[Casey]

optparse can handle options with a negative int value; "--" can be used to
signal that no more options will follow:

Thanks, Peter. getopt supports the POSIX "--" end of options
indicator as well, but that seems a little less elegant than being
able to simply set a value that tells the parser "I don't use any
numeric values as options, and I want to allow negative values as
arguments". At the parser level implemening this would be trivial and
I frankly was hoping it had been implemented and it just wasn't
mentioned in the spares Python getopt library reference.

 

[Peter Otten]

Thanks, Peter. getopt supports the POSIX "--" end of options indicator
as well, but that seems a little less elegant than being able to simply
set a value that tells the parser "I don't use any numeric values as
options, and I want to allow negative values as arguments". At the
parser level implemening this would be trivial and I frankly was hoping
it had been implemented and it just wasn't mentioned in the spares
Python getopt library reference.

After a quick glance into the getopt and optparse modules I fear that both
hardcode the "if it starts with '-' it must be an option" behaviour.

Peter

 

[J. Clifford Dyer]

If you can access the argument list manually, you could scan it for a negative integer, and then insert a '--' argument before that, if needed, before passing it to getopt/optparse. Then you wouldn't have to worry about it on the command line.

Cheers,
Cliff

 

[Nanjundi]

['-123']

Without the "--" arg you will get an error:

parser.parse_args(["-123"])

Usage: [options]

: error: no such option: -1
$

Peter

Passing -a-123 works

options, args = parser.parse_args(["-a-123"])
options.a

-123

-N

 

[Casey]

If you can access the argument list manually, you could scan it for a negative integer, and then insert a '--' argument before that,
if needed, before passing it to getopt/optparse. Then you wouldn't have to worry about it on the command line.

Cheers,
Cliff

Brilliant!

<code>
# Look for the first negative number (if any)
for i,arg in enumerate(sys.argv[1:]):
# stop if
if arg[0] != "-": break
# if a valid number is found insert a "--" string before it
which
# explicitly flags to getopt the end of options
try:
f = float(arg)
sys.argv.insert(i+1,"--")
break;
except ValueError:
pass
</code>

 

[Casey]

If you can access the argument list manually, you could scan it for a negative integer,
and then insert a '--' argument before that, if needed, before passing it to getopt/optparse.
Then you wouldn't have to worry about it on the command line.

Cheers,
Cliff

Brilliant!

# Look for the first negative number (if any)
for i,arg in enumerate(sys.argv[1:]):
# stop if a non-argument is detected
if arg[0] != "-": break
# if a valid number is found insert a "--" string before it which
# explicitly flags to getopt the end of options
try:
f = float(arg)
sys.argv.insert(i+1,"--")
break;
except ValueError:
pass

 

[Steven Bethard]

Is there an easy way to use getopt and still allow negative numbers as
args? [snip]
Alternatively, does optparse handle this?

optparse can handle options with a negative int value; "--" can be used to
signal that no more options will follow:

import optparse
parser = optparse.OptionParser()
parser.add_option("-a", type="int")

options, args = parser.parse_args(["-a", "-42", "--", "-123"])
options.a -42
args

['-123']

In most cases, argparse (http://argparse.python-hosting.com/) supports
negative numbers right out of the box, with no need to use '--':
-123


STeVe

 

[Neal Becker]

If you can access the argument list manually, you could scan it for a
negative integer, and then insert a '--' argument before that,
if needed, before passing it to getopt/optparse. Then you wouldn't have
to worry about it on the command line.

Cheers,
Cliff

Brilliant!

<code>
# Look for the first negative number (if any)
for i,arg in enumerate(sys.argv[1:]):
# stop if
if arg[0] != "-": break
# if a valid number is found insert a "--" string before it
which
# explicitly flags to getopt the end of options
try:
f = float(arg)
sys.argv.insert(i+1,"--")
break;
except ValueError:
pass
</code>

One person's "brilliant" is another's "kludge".

 

[Ben Finney]

In most cases, argparse (http://argparse.python-hosting.com/)
supports negative numbers right out of the box, with no need to use
'--':

-123

That would be irritating. I've used many programs which have numbers
for their options because it makes the most sense, e.g. 'mpage' to
indicate number of virtual pages on one page, or any number of
networking commands that use '-4' and '-6' to specify IPv4 or IPv6.

If argparse treats those as numeric arguments instead of options,
that's violating the Principle of Least Astonishment for established
command-line usage (hyphen introduces an option).

 

[Casey]

One person's "brilliant" is another's "kludge".

Well, it is a hack and certainly not as clean as having getopt or
optparse handle this natively (which I believe they should). But I
think it is a simple and clever hack and still allows getopt or
optparse to function normally. So I wouldn't call it a kludge, which
implies a more clumsy hack. As you say, it is all a matter of
perspective.

 

[Ben Finney]

Well, it is a hack and certainly not as clean as having getopt or
optparse handle this natively (which I believe they should).

I believe they shouldn't because the established interface is that a
hyphen always introduced an option unless (for those programs that
support it) a '--' option is used, as discussed.

But I think it is a simple and clever hack and still allows getopt
or optparse to function normally.

Except that they *don't* function normally under that hack; they
function in a way contradictory to the normal way.

So I wouldn't call it a kludge, which implies a more clumsy hack. As
you say, it is all a matter of perspective.

Everyone is entitled to their own perspective, but not to their own
facts.

 

[Steven Bethard]

That would be irritating. I've used many programs which have numbers
for their options because it makes the most sense, e.g. 'mpage' to
indicate number of virtual pages on one page, or any number of
networking commands that use '-4' and '-6' to specify IPv4 or IPv6.

Did you try it and find it didn't work as you expected? Numeric options
seem to work okay for me::

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-1', dest='one', action='store_true')
>>> args = parser.parse_args(['-1'])
>>> args.one

True

Argparse knows what your option flags look like, so if you specify one,
it knows it's an option. Argparse will only interpret it as a negative
number if you specify a negative number that doesn't match a known option.

STeVe

 

[Ben Finney]

Did you try it and find it didn't work as you expected?

No, I was commenting on the behaviour you described (hence why I said
"That would be irritating").

Argparse knows what your option flags look like, so if you specify
one, it knows it's an option. Argparse will only interpret it as a
negative number if you specify a negative number that doesn't match
a known option.

That's also irritating, and violates the expected behaviour. It leads
to *some* undefined options being flagged as errors, and others
interpreted as arguments. The user shouldn't need to know the complete
set of options to know which leading-hyphen arguments will be treated
as options and which ones won't.

The correct behaviour would be to *always* interpret an argument that
has a leading hyphen as an option (unless it follows an explicit '--'
option), and complain if the option is unknown.

 

[Neal Becker]

I believe they shouldn't because the established interface is that a
hyphen always introduced an option unless (for those programs that
support it) a '--' option is used, as discussed.

I don't agree. First of all, what is 'established interface'? There are
precedents from well-known C and C++ libraries, such as 'getopt', 'popt',
and boost:rogram_options. IIRC, each of these will treat a negative
number following an option that requires a number as a number.

Besides this, the behavior I just described is really required. Otherwise,
numeric options are basically broken.

 

[Steven Bethard]

That's also irritating, and violates the expected behaviour. It leads
to *some* undefined options being flagged as errors, and others
interpreted as arguments. The user shouldn't need to know the complete
set of options to know which leading-hyphen arguments will be treated
as options and which ones won't.

The correct behaviour would be to *always* interpret an argument that
has a leading hyphen as an option (unless it follows an explicit '--'
option), and complain if the option is unknown.

It was decided that practicality beats purity here. Arguments with
leading hyphens which look numeric but aren't in the parser are
interpreted as negative numbers. Arguments with leading hyphens which
don't look numeric and aren't in the parser raise errors. Sure, it's not
the pure answer, but it's the practical answer: "-123" is much more
likely to be a negative number than an option.

STeVe

 

[Casey]

I believe they shouldn't because the established interface is that a
hyphen always introduced an option unless (for those programs that
support it) a '--' option is used, as discussed.

Not "THE" established interface; "AN" established interface. There
are other established interfaces that have different behaviors. I'm a
pragmatist; I write software for users, not techies. I suspect most
users would expect a command like "abc -a -921 351 175" to treat the
"-921" as a negative integer and not abort the program with some
obscure error about option 921 not being known.

Except that they *don't* function normally under that hack; they
function in a way contradictory to the normal way.

Again, it depends on who is defining "normal" and what they are basing
it on. I suspect many (probably most) users who are familiar with
command line input are unaware of the "--" switch which was mainly
designed to support arbitrary arguments that might have an initial
hyphen, a much broader problem than supporting negative values. I'm
not asking that the default behavior of getopt or optparse change;
only that they provide an option to support this behavior for those of
us who find it useful. Software libraries should be tools that support
the needs of the developer, not rigid enforcers of arbitrary rules.

 

[Steven Bethard]

Not "THE" established interface; "AN" established interface. There
are other established interfaces that have different behaviors. I'm a
pragmatist; I write software for users, not techies. I suspect most
users would expect a command like "abc -a -921 351 175" to treat the
"-921" as a negative integer and not abort the program with some
obscure error about option 921 not being known.

Glad I'm not alone in this. ;-) A user shouldn't have to go out of their
way to specify regular numbers on the command line, regardless of
whether they're positive or negative.

STeVe

 

[Ben Finney]

A user shouldn't have to go out of their way to specify regular
numbers on the command line, regardless of whether they're positive
or negative.

A user shouldn't have to go out of their way to know whether what they
type on a command line will be treated as an option or an argument.