Click 8.0 Custom Parameter Types and convert()

[makermelissa]

It appears the actual values are coming through rather than strings of the values which is causing some unexpected results.

[makermelissa]

This code works fine in 7.1.2, but fails in 8.0.0. Documentation doesn't note that the values should have changed. I don't have the exact error anymore, but value was an int, so it choked on value.lower() since you can't call lower() on an int.

class BasedIntOrNoneParamType(click.ParamType):
    name = 'Int or None'

    def convert(self, value, param, ctx):
        try:
            if value.lower() == 'none':
                return 'none'
            return int_as_text_to_int(value)
        except nRFException:
            self.fail('%s is not a valid integer' % value, param, ctx)

BASED_INT_OR_NONE = BasedIntOrNoneParamType()

The code is from here:
https://github.com/adafruit/Adafruit_nRF52_nrfutil/blob/master/nordicsemi/__main__.py#L59-L70

[davidism]

The value processing did change somewhat, and converters may get values that are already the correct type in situations such as using a default value or passing values from Python code instead of the command line. The reason for this change is so that type casting is applied consistently throughout the processing pipeline, regardless of how the command is called or where the value comes from.

My guess is that you have a default=10 or something, and that's getting passed through. The relevant changelog line is probably this one (admittedly there's a lot to sift through this time), or one of the others from #1687:

When getting the value for a parameter, the default is tried in the same section as other sources to ensure consistent processing. #1649

You can adapt your custom type with something like this:

def convert(self, value, param, ctx):
    if isinstance(value, int):
        return value

If this isn't the issue, can you post a self-contained example and the error you get?

[JNRowe]

I'm also experiencing the same issue with version 8.0. While the isinstance() check will resolve it for me, I'm just looking to check the repeated calls to convert() are the expected behaviour now before I make the changes. For example, using the custom types example will break if a default is given:

@click.command()
@click.option('-n', type=BASED_INT, default=10)
def main(n):
    pass

fails with Error: Invalid value for '-n': expected string for int() conversion, got 10 of type int. If this is expected behaviour, perhaps the docs need updating?

[makermelissa]

Thanks. I think I can get past my particular issue by wrapping the value inside of str().