You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
name = 'Int or None'
def convert(self, value, param, ctx):
if value.lower() == 'none':
self.fail('%s is not a valid integer' % value, param, ctx)
BASED_INT_OR_NONE = BasedIntOrNoneParamType()
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:
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: