Click 8 changed the processing pipeline in an effort to be more consistent. Part of that made fetching the default value happen in the same area of code as fetching the value from other sources, then processing whatever value was fetched. However, get_default still calls type_cast_value, which was a holdover from the previous code.
This causes default values to be type cast twice, once when fetching the default value, then again when processing the value. It also causes the default to be type cast when showing the help text, which can lead to unexpected output, such as the string representation of an open file object instead of the filename.
In general, custom parameter types should still be able to handle being passed a value of the correct type. This can still happen if the default is the correct type, or when prompting (which converts the value to the type for validation before returning), or when passing arguments to main() from Python instead of the command line.
Fetching the default value should behave more like the other source handled in consume_value. Env vars and context defaults are not type cast, so the default should not be either. This should prevent the most common source of issues with existing custom types (although they should still be updated to work as described above).
Related to:
There are still some other unexpected behaviors, such as type casting flag_value, but that will have to be handled separately.
Click 8 changed the processing pipeline in an effort to be more consistent. Part of that made fetching the default value happen in the same area of code as fetching the value from other sources, then processing whatever value was fetched. However,
get_defaultstill callstype_cast_value, which was a holdover from the previous code.This causes default values to be type cast twice, once when fetching the default value, then again when processing the value. It also causes the default to be type cast when showing the help text, which can lead to unexpected output, such as the string representation of an open file object instead of the filename.
In general, custom parameter types should still be able to handle being passed a value of the correct type. This can still happen if the default is the correct type, or when prompting (which converts the value to the type for validation before returning), or when passing arguments to
main()from Python instead of the command line.Fetching the default value should behave more like the other source handled in
consume_value. Env vars and context defaults are not type cast, so the default should not be either. This should prevent the most common source of issues with existing custom types (although they should still be updated to work as described above).Related to:
click.File()option shown as<_io.TextIOWrapper [...]>#1999There are still some other unexpected behaviors, such as type casting
flag_value, but that will have to be handled separately.