Open mikeshardmind opened 1 year ago
Apologies for the delayed response here. In the long run I intend to support generic bound constraints, so something like this should work. But beyond a workaround for #487, can you think of a use case for <
/>
constraints for IntEnum
types?
Outside of as a workaround for #487, probably not. IntEnums already come with boundary checks (even included in the example there) for internal to the enum situations. I'd probably avoid forbidding it unless it adds to the costs involved somewhere you think needs considering (either for you on maintaining, performance for those not using it, etc.) so that it could be transparently mostly compatible with integers; However, I can't say that I have or see a motivating case beyond less surprising behavior.
Description
This seems related to #487 , but I came across a slightly different case of it.
This was done in an initial attempt to work around the inability to specify this with
Literal[SomeEnum.empty, SomeEnum.a]
in a situation where only that subset of the enum is valid for that particular field to ship something now, then add more info to the related issue.I've left the original names and module names out as irrelevant, but it would seem that IntEnums should be considered numeric types for the constraints addable with Meta