getopt with negative numbers?
Casey
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
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")
<Option at 0xb7d6fd8c: -a>
>>> 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
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
Cheers,
Cliff
Nanjundi
> >>> args
>
> ['-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!
# 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?
> Alternatively, does optparse handle this?
Peter Otten wrote:
> 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")
> <Option at 0xb7d6fd8c: -a>
>>>> 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 '--':
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-a', type=int)
>>> parser.add_argument('b', type=int)
>>> args = parser.parse_args('-a -42 -123'.split())
>>> args.a
-42
>>> args.b
-123
STeVe
Neal Becker
> On Sep 27, 2:21 pm, "J. Clifford Dyer" <j...@sdf.lonestar.org> wrote:
>> 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
> '--':
>
> >>> import argparse
> >>> parser = argparse.ArgumentParser()
> >>> parser.add_argument('-a', type=int)
> >>> parser.add_argument('b', type=int)
> >>> args = parser.parse_args('-a -42 -123'.split())
> >>> args.a
> -42
> >>> args.b
> -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).
--
\ "I went to a general store. They wouldn't let me buy anything |
`\ specifically." -- Steven Wright |
_o__) |
Ben Finney
Casey
> One person's "brilliant" is another's "kludge".
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.
--
\ "[...] a Microsoft Certified System Engineer is to information |
`\ technology as a McDonalds Certified Food Specialist is to the |
_o__) culinary arts." —Michael Bacarella |
Ben Finney
Steven Bethard
> Steven Bethard <steven....@gmail.com> writes:
>
>> In most cases, argparse (http://argparse.python-hosting.com/)
>> supports negative numbers right out of the box, with no need to use
>> '--':
>>
>> >>> import argparse
>> >>> parser = argparse.ArgumentParser()
>> >>> parser.add_argument('-a', type=int)
>> >>> parser.add_argument('b', type=int)
>> >>> args = parser.parse_args('-a -42 -123'.split())
>> >>> args.a
>> -42
>> >>> args.b
>> -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.
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.
--
\ "When I was a kid I used to pray every night for a new bicycle. |
`\ Then I realised that the Lord doesn't work that way so I stole |
_o__) one and asked Him to forgive me." -- Emo Philips |
Ben Finney
Neal Becker
> Casey <Case...@gmail.com> writes:
>
>> 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.
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::program_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
>> 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.
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
wrote:
> 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.
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.
>
> > 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.
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
> Ben Finney wrote:
>> 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.
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.
--
\ "When I was crossing the border into Canada, they asked if I |
`\ had any firearms with me. I said, 'Well, what do you need?'" |
_o__) -- Steven Wright |
Ben Finney
Carl Banks
What if (for example) you define a option "-3", and also accept
numerical arguments on the command line. Then you could get sudden
unexpected behavior if you input the wrong number:
"./hello -1" works ok.
"./hello -2" works ok.
"./hello -3" ... whoops, now the negative number is suddenly an
option.
Granted, it would be stupid for a program to do that, but it suggests
to me that it's probably a good idea to treat all negative numbers the
same. I.e. if there are any numerical options, then all negative
numbers are treated as options. If there are none, then negative
numbers are treated as numbers.
Carl Banks
Carl Banks
wrote:
> Steven Bethard <steven.beth...@gmail.com> writes:
> > 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.
I guess typing
./program --help
is out of the question.
Carl Banks
Steven Bethard
That's probably a good guideline. Anyone mixing numeric flags with
negative number arguments is asking for an exception of some sort. ;-)
I'm going to let it sit for a while and think about it, but I'll
probably make that change in the next release.
STeVe
Ben Finney
You're trying to have it both ways.
You're saying the user "shouldn't have to go out of their way" to type
arbitrary arguments on the command line. Then, in your next message,
you suggest they must *read the detailed command-line help* in order
to know whether they *can* type arbitrary command-line arguments.
Is "learn about how the program expects options and arguments" within
your definition of "go out of their way", or isn't it? If it's not,
then "shouldn't have to go out of their way" is *not* an argument in
favour of special-casing negative-numbers.
--
\ "We spend the first twelve months of our children's lives |
`\ teaching them to walk and talk and the next twelve years |
_o__) telling them to sit down and shut up." -- Phyllis Diller |
Ben Finney
Carl Banks
wrote:
> Carl Banks <pavlovevide...@gmail.com> writes:
> > On Sep 28, 6:19 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
> > wrote:
> > > Steven Bethard <steven.beth...@gmail.com> writes:
> > > > 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.
>
> > I guess typing
> > ./program --help
>
> > is out of the question.
>
> You're trying to have it both ways.
>
> You're saying the user "shouldn't have to go out of their way" to type
> arbitrary arguments on the command line.
No, I'm not. Don't put words in my mouth.
I don't think it's "going out of your way" to read the documentation,
or to put a couple hyphens on the line. Those were your words, and
they were an utterly silly hyperbole.
> Then, in your next message,
> you suggest they must *read the detailed command-line help* in order
> to know whether they *can* type arbitrary command-line arguments.
You're writing a program that takes numerical positional arguments.
Are you being more of asshole ir you
A. Expect me to read the documentation, or
B. Force me to type two hyphens every single time I want to enter a
negative number?
I would say B by a mile.
Not that it's "going out of my way" to enter the extra hyphens; it's
just irritating and completely, totally, and utterly unnecessary.
> Is "learn about how the program expects options and arguments" within
> your definition of "go out of their way", or isn't it? If it's not,
> then "shouldn't have to go out of their way" is *not* an argument in
> favour of special-casing negative-numbers.
It's only a special case in your imagination. Try typing this:
seq -9 -1
On my system, seq is a GNU tool, and the guys at the FSF are some of
the biggest tightwads around when it comes to command line options.
Even when they allow nonconformant options for the sake of backwards
compatibility, they run a guilt trip on you. But even they see the
practicality in allowing negative number arguments in some cases.
Carl Banks