Guido van Rossum <guido@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