Enumeration idioms: Values from different enumerations

[Mike Meyer]

Peter Hansen <peter at engcorp.com> writes:
> For example, if enumerations are intended to reduce the likelihood of
> certain types of errors (where the use of typical XXXX=3 "constants"
> might be more prone to errors), then perhaps this suggests that
> passing errors silently is bad.  That is, 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.

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). Do any python builtins behave that way? How about anything in
the python standard library?

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