flag_value converted to str in Click 8

[jwodder]

Consider the following code:

import click

@click.command()
@click.option("--answer", flag_value=42)
def main(answer):
    click.echo(repr(answer))

if __name__ == '__main__':
    main()

Under click 7, passing the --answer option to this script prints 42 (an int), as expected. Under click 8, it prints '42' (a str).

Environment:

• Python version: 3.9.5
• Click version: 7.1.2 vs. 8.0.0

[davidism]

The default type of parameters is str. You need to specify type=int if you want int values.

[jwodder]

@davidism OK, but in my actual use case, the flag_value is an instance of a class with a zero-argument constructor. How am I expected to get that to work? Trying @click.option("--answer", is_flag=True, type=Klass) (and also with flag_value=None) results in a Klass() takes no arguments TypeError.

[davidism]

Then it should use type=click.UNPROCESSED to pass the value through unchanged.

[davidism]

I think what's affecting this is that we now apply type casting consistently to any value coming through the pipeline. I wonder if setting the type to unprocessed automatically for flag values is safe.

[jwodder]

@davidism Using type=click.UNPROCESSED works, thanks.

[crashfrog]

The most basic option is a value option. These options accept one argument which is a value. If no type is provided, the type of the default value is used.

Click 8.0.0 appears to ignore the type of the default value of options if type is not given:

bugval = functools.partial(range, 10)

@click.command()
@click.option('-b', 'bug', default=bugval, flag_value=bugval)
def cli(bug):
    print("type of bug:", type(bug), "value of bug", bug)

$ python click_bug.py   
type of bug: <class 'str'> value of bug functools.partial(<class 'range'>, 10)

[davidism]

I'm sorry, I can't tell what you're trying to demonstrate with that example. It seems at best tangentially related to this issue, but it's not clear at all.

[crashfrog]

Sorry, I thought the example was fairly obvious: as per the documentation (quoted from 8.0.0), and as it works in 7.1.2, Click should infer the type of the value from what's given to default, but in 8.0.0 the type of the default value is ignored and the flag value is cast to str instead.

This is pretty clearly a bug; the same bug for which the issue was opened, in fact.

[davidism]

The default you gave is dynamic, so it wouldn't be able to infer a type anyway.

[crashfrog]

It's not dynamic, it's the value of bugval - a functools.partial object.

[davidism]

Which is a callable, not a literal value.

[ThiefMaster]

A callable is dynamic...

[crashfrog]

A functools.partial is a callable, literal value that has a type (functools.partial, specifically.)

[davidism]

@crashfrog sorry, it sounds like we're having trouble explaining the difference. You're going to have to trust us that there is, in fact, a difference, this tangent is derailing this issue.

[crashfrog]

I'm not sure what you're having trouble explaining - in 7.1.2 it works to pass callable values as default and flag_value, which is extremely useful for things like flags that set output formats (TSV vs. JSON vs. XML, for instance.)

In 8.0.0 this behavior is broken because click.option now ignores the default argument's type and converts callable values to strings when there's no type argument. Since this isn't described in the documentation and it's a breaking change from 7.1.2, it's pretty obviously a bug and it's exactly the bug described in the issue; this is an example of it.

https://click.palletsprojects.com/en/8.0.x/changes/#version-8-0-0

Here's the patch notes; I don't see where it says "we now convert all callable values to str" or something, and even if that were in the notes, that's undesirable behavior.