Option.is_bool_flag is set to True even if the option is not a flag

[janluke]

This is relevant only for Click 8.0.1, since the following line was introduced in PR #1913:

click/src/click/core.py

Line 2531 in af0af57

self.is_bool_flag = isinstance(self.type, types.BoolParamType)

The solution is as easy as:

self.is_bool_flag = self.is_flag and isinstance(self.type, types.BoolParamType)

Available to open a PR.

Demonstration code

import click

@click.command()
@click.option('--switch', type=bool)
def f(switch):
    print(switch)


if __name__ == '__main__':
    assert not f.params[0].is_flag
    assert f.params[0].is_bool_flag
    f('--switch'.split())

Error: Option '--switch' requires an argument.

[frenzymadness]

Not sure if this is related but an option defined like this:

@click.option("--code", nargs=1, default=False, help="Foo")

Had a type TEXT in click 7

# python3 test.py --help
Usage: test.py [OPTIONS]

Options:
  --code TEXT  Foo
  --help       Show this message and exit.

and now has a type BOOLEAN in click 8.

# python3 test.py --help
Usage: test.py [OPTIONS]

Options:
  --code BOOLEAN  Foo
  --help          Show this message and exit.

I'm trying to fix it in pipenv because I think the type should be explicitly defined: pypa/pipenv#4726

[janluke]

@frenzymadness Your thing is not related to this issue specifically, but it's related to the same PR. The flag_value attribute is always set to not default by Click, even if the options is not a flag. That, combined with the PR, seems to be the source of the change (but I could be wrong).

I'd say the new behavior makes much more sense. What's the point of setting a string options to False? You can just omit default (*) or set it to "".

(*) this should be the preferred solution, especially if you need to handle the "not provided" case separately and you are using static typing.