-
Notifications
You must be signed in to change notification settings - Fork 2
Closed
Labels
breaking changesThis issue will cause a breaking change (or deprecation warning).This issue will cause a breaking change (or deprecation warning).enhancementImprovements to existing features or smaller new featuresImprovements to existing features or smaller new features
Milestone
Description
Making the EnumValidator case insensitive is useful in a lot of cases, and should almost never cause any problems (only if you have an enum with two string values that are basically the same string but differently capitalized - in which case you're dealing with very questionable design decisions...).
Because of this, I would opt to make case insensitive the default for the EnumValidator (and the AnyOfValidator too).
For a more intuitive API, I would also suggest to "reverse" the parameter, changing it to case_sensitive (with default: False), otherwise you'd have a double negative if you want to override the default (case_insensitive=False).
This would obviously be a breaking change, or rather, two breaking changes:
- Changing the default behaviour is a breaking change. However, as argued above, I don't think this will affect anyone negatively in practice.
- Renaming the parameter is a breaking change that will have effects on all code that uses the parameter. So for compatibility, I'd suggest adding a new parameter
case_sensitive, which of course is mutually exclusive with the existing parameter, deprecate the old parameter and finally remove it version 1.0.
Metadata
Metadata
Assignees
Labels
breaking changesThis issue will cause a breaking change (or deprecation warning).This issue will cause a breaking change (or deprecation warning).enhancementImprovements to existing features or smaller new featuresImprovements to existing features or smaller new features