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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
