On Fri, Apr 12, 2013 at 3:44 PM, Barry Warsaw <ba...@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)
_______________________________________________
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
