Enumeration idioms: Values from different enumerations

[Mike Meyer]

Ben Finney <bignose at polar.local> writes:
> Mike Meyer <mwm at mired.org> writes:
>> Peter Hansen <peter at engcorp.com> writes:
>>> That is, [perhaps] trying to compare enumerations that should not
>>> be compared *is* an error (raising an exception) *because* the
>>> whole point of enumerations is to avoid errors in such cases.
>> Except it might not be an error. For instance, if I've got a list of
>> enum objects taken from various types (say I've got one set of enums
>> for days of the week, another for months of the year, and so on, and
>> which I use depends on whether the user wants to select days of the
>> week, months of the year, etc), it makes perfect sense to want to know
>> if a specific enum value is in the list, and the obvious way to check
>> it is with "my_value in enum_list". That won't work if you raise an
>> exception - it takes a relatively convoluted bit of code to make this
>> test.
> What's being discussed here is what happens when comparing the *values*
> from the enumeration.

That's what I thought I was discussing, but apparently I wasn't clear
enough. Let me try again.

I think it's perfectly reasonable to store enum values from different
enums in a list, and check for a specific value being in that list. If
comparing two enum values can raise an exception, then doinng this
become problematic, as you may get an exception. According to what you
say below, this isn't true for any builtin type or any type in the
standard library.

>> Python generally uses '==' to mean "is the same value".  To do that,
>> a simple true/false return is enough. In raising an exception,
>> you're making '==' carry an extra meaning (I'm not sure *what* that
>> is, though).
> The problem with "is the same value" as an explanation for '==' is
> that it doesn't help in cases such as::
>     >>> ShirtSize = Enum('small', 'medium', 'large')
>     >>> AppleSize = Enum('small', 'large')

Actually, it provides a very explicit guideline for these cases. The
guidelines is by no means obvious, as witness languages like LISP,
which have multiple equality operators.

> What should be the result of this comparison::
>     >>> ShirtSize.small == AppleSize.small
> Are they "the same value"? They're both "small" (and they both coerce
> to the same string value, and in this case the same integer value).

That depends on the semantics you want to place on the values of
enums. Reasonable arguments can be made for anything from "they're
exactly like small integers" to "the values are an implementation
detail, and you shouldn't worry about them." That they coerce to the
same string is irreleevant, at least in python, which doesn't coerce
strings to

>> Do any python builtins behave that way? How about anything in the
>> python standard library?
> No to both; I believe this may be a defining property of
> enumerations. Am I wrong?

There are enum implementations that don't treat comparing enum values
from different enums as an error, so I'd say you're wrong. In Python's
case, comparing two objects for identity never raises an exception for
any type that comes with the language, so I'd say that that was a
defining property of python.

         <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.