On Thu, 28 Jun 2018 08:36:47 -0700, Ethan Furman wrote:
>>> Answer:
>>>
>>> - 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
methods?
Perhaps you could have had an explicit decorator?
class Colours(Enum):
RED = 1
class Spam(object):
pass
@Enum.member
class Eggs(object):
pass
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:
type(Colour.RED)
=> returns Colour.PrimaryColour
But maybe there's another way to get that same effect?
# ???
class PrimaryColour(Enum):
RED = 1
...
class SecondaryColour(Enum):
...
Colour = PrimaryColour + SecondaryColour
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
