[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