[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)

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 f (where is any comparison operator) defer to e.value f.value ? Or is the problem with 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