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

Guido van Rossum guido at python.org
Sat Apr 13 00:59:04 CEST 2013

On Fri, Apr 12, 2013 at 3:44 PM, Barry Warsaw <barry at python.org> wrote:
> 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.

No, my proposal was only meant for if the classes are the same. If the
classes are different the comparison should always fail.

> 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

Right, I *only* meant this as a way to differentiate between bee and wasp in:

class Insect(Enum):
    wasp = 1
    bee = 1
    ant = 2

We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is
not Insect.bee.

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list