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
True and False are cast consistently by int, float and decimal.Decimal.
They are explicitely rejected in Number._validated.
I'd rather we keep a consistent interface here for all number fields. Accepting booleans could be set by yet another field init parameter. Not sure.
Or maybe extend strict to all number fields and reject booleans if strict is True for all number fields alike.
Not sure this ought to be in Number, though. Just because all currently child fields auto-cast, does not mean any child field would. What about a custom field inheriting from Number but for a type that cannot cast booleans.
Overall, I'm wondering whether we should fix the code or the docs.
Actually the strict option doesn't do the job as it should be. For example, if you set strict=True, Integer field will still accept the float type. So removing that parameter entirely can also be an option.
But of course, if you want to keep the backward compatibility we should fix it.
I think extending that parameter to Number is not a good idea since it has no use in Decimal field which is inheriting from Number
As mentioned in the documentation, for
Integer
fields when the strict parameter is False any value that is castable to integer is acceptable:But actually, if you pass True or False when strict is False the validation will fail although boolean values are castable to int:
The text was updated successfully, but these errors were encountered: