Should nested classes in an Enum be Enum members?
On Thu, 28 Jun 2018 08:36:47 -0700, Ethan Furman wrote:
>>> - RED, GREEN, and BLUE are members
>>> - lower and spam() are not
>>> - SomeClass /is/ a member (but not its instances)
>> Is that by accident or by design?
> By design. It is entirely possible to want an enum of types (int,
> float, str, etc.).
Seems strange to me. Why enum of types but not an enum of functions or
Perhaps you could have had an explicit decorator?
RED = 1
Colours.Eggs will be an enum member, Spam will not be.
But I suppose backwards compatibility rules that out.
>> class Colour(Enum):
>> class PrimaryColour(Enum):
>> RED = 1
>> GREEN = 2
>> BLUE = 3
>> OCTARINE = 8
>> class SecondaryColour(Enum):
>> PUCE = 101
>> MAUVE = 102
>> BEIGE = 103
>> TEAL = 104
> This really seems to be the sticking point -- what should an Enum of
> Enums look like? For example, should the above do
> --> list(Colour)
> [Colour.PrimaryColour <...>, Colour.SecondaryColour <...>]
> or something else?
I would expect the inner classes to disappear:
[Colour.RED, Colour.GREEN, ... Colour.PUCE, ... ]
unless I explicitly inspect their types:
=> returns Colour.PrimaryColour
But maybe there's another way to get that same effect?
RED = 1
Colour = PrimaryColour + SecondaryColour
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson