Click: Cannot pass negative numbers as arguments

[Kitchi]

If I try to pass a negative number to click, it interprets it as an option. This happens when I define the number either as int, float or leave it to default to string.

Here's a tiny example to illustrate the issue

import click

@click.command()
@click.argument('number', type=float)
def main(number):
    print(number)

if __name__ == '__main__':
    main()

and I run it as

❯ python tmp.py '-10'
Error: no such option: -1

or even as

❯ python tmp.py -10
Error: no such option: -1

EDIT: I am running Python 3.5.1 and Click version 6.3 installed through the Anaconda python distribution.

[ZeeD26]

Try

python tmp.py -- -10

see http://click.pocoo.org/6/arguments/#option-like-arguments

[Kitchi]

@ZeeD26 That worked! Out of curiosity - Would it be useful to have a feature in click (probably passed through the context setting) that forces it to read the first N command line inputs as the arguments and only then read the options?

That would effectively be the reverse of the current situation, since I will have to specify the options first followed by -- and then the arguments.

[untitaker]

I'm unsure if that is useful. Feel free to open a new issue about that, I'm going to close this one because this parsing behavior is basically impossible to get fixed.

[scottstanie]

Why is it that argparse is able to handle this case? Does it not allow single dash options to begin with a number, and is that something that click purposely wants to allow (a number as option with no space in between)?

import argparse
p = argparse.ArgumentParser()
p.add_argument('number', type=float)
args = p.parse_args()
print(args.number)

$ python argtest.py -10
-10.0

[untitaker]

@scottstanie restricting options to pure integers would be a way to mitigate this, but the issue still pertains when you want to pass something like -infinity as a number value. Also it would be a compat breaking change so I am not sure if this is worth fixing at this point vs just dealing with it (tbh I don't see the problem with adding -- -- that's basically how git's CLI parser works)

[scottstanie]

gotcha thanks for the quick response, I hadn't seen the -- in git or other CLIs before, so I didn't know it standard.

[pjz]

I also just bumped into this. The suggested workaround... is a workaround. It should be possible to disambiguate by checking:

1. if any options/flags match first, then fine, but if not, it's an arg
2. some special marker in an arg indicating "this might be a negative number, so don't treat it as an option/flag if it looks like one"
3. simpler but less powerful, I'd be fine with a pure system-wide flag to disable numeric options/flags - I don't use them often, and would be happy to not use them if it'd make my user's lives easier.

[cwoodall]

I also still think this is pretty irritating @pjz has a pretty good fix outlined.

[davidism]

A -- token disables option parsing so all further tokens are considered arguments.

python example.py -- -10