[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?
> 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"?
> Because as it is you can't put elements from different enumerations
> in a list and check with the in operator if a specific enum value is
> in the list.
>
> It could also cause problems for dictionaries, since keys in
> dictionaries can be tested against a key giving in a subscription.
These are valid concerns. I can't see how to reconcile these against
the desire for values from different enums to fail comparison.
Am I alone in my tri-state view of enumeration value comparisons? Can
anyone else defend why values from different enumerations should not
compare?
--
\ "I was the kid next door's imaginary friend." -- Emo Philips |
`\ |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
