Numeric command-line options vs. negative-number arguments

[Carl Banks]

On Sep 28, 9:51 am, Steven Bethard <steven.beth... at gmail.com> wrote:
> Ben Finney wrote:
> > Steven Bethard <steven.beth... at gmail.com> writes:
> >> 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.
>
> 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.

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