[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Barry Warsaw barry at python.org
Sat Apr 13 00:44:49 CEST 2013


On Apr 12, 2013, at 02:34 PM, Guido van Rossum wrote:

>So, pragmatically, if e and f are values of the same enum class,
>couldn't e <cmp> f (where <cmp> is any comparison operator) defer to
>e.value <cmp> f.value ? Or is the problem with <cmp> being == and e
>and f being different enum values with the same underlying value? But
>that's already iffy, isn't it? (Barry's favorite solution for
>serializing to a database wouldn't work either.) And they could still
>be distinguished by using 'is' instead of '=='.

If I'm parsing that correctly, yes, I think we don't want to defer to the
enum.value for the base enum type because unrelated enumeration values should
not compare equal.

E.g.

class Colors(Enum):
    red = 1
    blue = 2
    green = 3

class Animals(Enum):
    ant = 1
    bee = 2
    cat = 3

In this case, Animals.bee != Colors.blue.

Of course, they would be == if they derived from IntEnums.

While I personally recommend and use identity to compare enum types, it seems
to be difficult to convince other users to also do so.  We could enforce this
by not implementing __eq__ and __ne__, but it seems worse to disallow this
than to make it work.  E.g.

    if shape.color is Colors.red:
        # works

    if shape.color == Colors.red:
        # throws an exception

-Barry


More information about the Python-Dev mailing list