On Sun, Dec 13, 2020 at 12:34:27AM -0800, Ethan Furman wrote:
[me]
> >>>>class MyValue(int, Enum):
> >... ONE = 1
> >... TWO = 2
> >...
> >>>>MyValue.TWO + 3
> >5
>
> 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 :-)
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/T75R4PG34I6XJUHUB5UAKGTYC5TAHRGW/
Code of Conduct: http://python.org/psf/codeofconduct/
