[Python-ideas] Enums
Ben Finney
ben+python at benfinney.id.au
Thu Jul 28 06:49:56 CEST 2011
Guido van Rossum <guido at python.org> writes:
> TBH, I'm not sure we should hold our breath until we have the perfect
> solution.
That's an important principle, certainly.
> Looking over flufl.enum again, I like most of its design decisions
> except the "enums are not integers" part. For me, after the above
> definition of class Color, I'd be happy of Color.red == 1, as long as
> str(Color.red) == 'red'.
I am displeased if we don't get this::
>>> Color.red == 1
False
>>> Fruit.tomato == 1
False
but wouldn't want to block an ‘enum’ implementation waiting for that.
What I'd hold out for, though, is::
>>> Color.red == Fruit.tomato
False
That is, all of the values from Color should compare as inequal with any
other value.
This is one of the main features to want from an enumerated type, IMO:
to have a set of values that are distinct from any other value, that
won't be accidentally equal to any other value, and have helpful string
representations.
> (Here I am consistent with the behavior of True and False.)
Do you see that (the behaviour of True and False comparing equal with
integers) as anything more than backward-compatible baggage?
To me, if I had the time machine, a proper representation of a boolean
type would have True and False as distinct values, never comparing equal
with any other value.
--
\ “Any intelligent fool can make things bigger and more complex… |
`\ It takes a touch of genius – and a lot of courage – to move in |
_o__) the opposite direction.” —Albert Einstein |
Ben Finney
More information about the Python-ideas
mailing list