On Sun, Dec 13, 2020 at 12:34:27AM -0800, Ethan Furman wrote:
class MyValue(int, Enum):
... ONE = 1 ... TWO = 2 ...
MyValue.TWO + 3
It certainly can be abused for that, but the intended purpose of IntEnum is not to support math operations, but rather to interoperate with existing APIs that are using ints as magic numbers.
Sure, but "ints as magic numbers" are a bit of a special case. If TOPLEFT and BOTTOMRIGHT are magic numbers
(TOPLEFT + BOTTOMRIGHT)//2
is unlikely to make any semantic sense. But I only used int because you did :-) A better example, stolen from your earlier one:
class K(frozenset, Enum): DIGITS = frozenset("0123456789") LETTERS = frozenset(string.ascii_letters)
DIGITS | LETTERS makes perfect semantic sense. Tell me that's abuse, I double-dare you :-)
The bottom line here is that all of the functionality you suggest makes sense, but I'm not convinced that the right API is a new and independent data type unrelated to Enum. Everything you suggest sounds to me like a variation on Enum:
- a way to add new members to an Enum after creation
- a way to create duplicate Enum values that aren't aliases
- a way for enums to automatically inherit behaviour from their values, without explicitly mixing another subclass.
These feel like add-ons to the basic Enum data type, not a full-blown independent data type.
Or maybe it's just that I don't like the name NamedValue. (Too vague -- `x = 1` is a named value. Maybe if you called it FancyEnum or something I'd love it :-)