Enumeration idioms: Values from different enumerations

[Antoon Pardon]

Op 2005-12-16, Ben Finney schreef <ben+hates-spam at benfinney.id.au>:
> [quoting private email with permission]
>
> Antoon Pardon wrote:
>> I just downloaded your enum module for python [from the Cheeseshop]
>> and played a bit with it. IMO some of the behaviour makes it less
>> usefull.
>
> Feedback is appreciated. I'm hoping to provide a "one obvious way" to
> do enumerations in Python.
>
>> >>> from enum import Enum
>> >>> day = Enum('mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun')
>> >>> col = Enum('red', 'green', 'blue')
>> >>> day.wed == col.blue
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>   File "enum.py", line 100, in __cmp__
>>     raise EnumValueCompareError(self, other)
>> enum.EnumValueCompareError: Not values from the same enumeration:
>> (EnumValue(<enum.Enum object at 0x4020c30c>, 2, 'wed'),
>> EnumValue(<enum.Enum object at 0x4021a14c>, 2, 'blue'))
>> >>> type(day.mon) == type(col.red)
>> True
>> >>> type(day.mon) is type(col.red)
>> True
>> >>> lst= [day.mon, col.red]
>> >>> day.fri in lst
>
>> As can be seen from the above, you raise an exception when one wants
>> to compare Enums from different enumarations, but it seems a bit
>> strange that different enumerations belong to the same type.
>
> This does seem a point that could be confusing. Would it be better if
> every Enum instance had its own unique subclass of EnumValue, that was
> used to instantiate values for that enumeration?

If you decide on keeping the current behaviour when comparing
values of different enumerations, I would definitely answer
yes.

>> I also think it would be more usefull if enums from different
>> enumerations just tested unequal.
>
> My rationale for this is: The only purpose of an enumeration is to
> have a set of arbitrary unique values within that enumeration. The
> values make no sense in the context of a different enumeration, so I
> see three different comparison results:
>
>     >>> Weekday.mon == Weekday.mon
>     True
>     >>> Weekday.fri == Weekday.mon
>     False
>     >>> Colour.blue == Weekday.mon
>     [...]
>     enum.EnumValueCompareError: Not values from the same enumeration
>
> However, I'm aware that this is not how other Python types behave:
>
>     >>> 23 == 23
>     True
>     >>> 42 == 23
>     False
>     >>> "spam" == 23
>     False
>
> Is there a semantic difference between these cases? Is that difference
> enough to want different behaviour?
>
> Is there some behaviour other than "evaluate to False" or "raise an
> exception", that could indicate "not comparable"?

This is a difficult question, because AFAIU python doesn't have clear
guidelines for this. I also have the impression that comparisons are
used for two different reasons.

The first is compare things in a mathematical kind of way in which
how things are compared is important.

The second is more an ordering mechanisme. Whether a string is greater
than an int or vice versa, is not imporant what is important is that
this order is consistent and can be used in binary searches, trees
and other structures to organise data.

Now python has only one collection of compare operators which can
cause conflicts. For instance, one could impose an order on sets
to use for such structure but that goes against the normal order
on sets which is based on subsets.

The only advise I have here is look at PEP 3000 that states:

Comparisons other than == and != between disparate types will raise
an exception unless explicitly supported by the type.

Which seem to imply that == and != should not raise an exception
but >, >=, <, <= should.

-- 
Antoon Pardon