Enumeration idioms: Values from different enumerations

Steven D'Aprano steve at REMOVETHIScyber.com.au
Fri Dec 16 19:17:43 EST 2005


On Fri, 16 Dec 2005 19:45:51 +1100, Ben Finney wrote:

> 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')
> 
> 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).

I don't think anyone seriously intends to argue that ShirtSize.small
should test equal to AppleSize.small.



> If not, is 'False' the right way to indicate that?

Why not? The intuitive answer is that they are "not equal".

In the case of apples and shirts, the intuitive answer can be misleading
because if you had a small enough shirt (say, for a Barbi doll) one might
be tempted to say "Yes, they are the same size".

A better example might be StringLength.long == BookSize.long. Both coerce
to the same string, but one measures physical length and the other
measures number of words. They are incompatible measures, and can't be
ordered. A strict physicist might argue that asking "is five kilograms
equal to three metres?" is a nonsensical question, but that's not the
Python way.

(And an even better physicist will answer that kilograms and metres can
not only be tested for equality, but can be ordered -- there are
mathematical transformations, common in relativistic physics, where all
physical quantities including time and mass, are transformed into lengths.
These physicists calculated *everything* in terms of dimensionless values
and multiples of length, length squared, length cubed, etc.)



> Or is it an error to even try comparing them?

Perhaps there are unusual cases where comparing strings and ints for
equality should be an error. There may even be unusual cases where
comparing ints and floats should be an error. But I don't believe that
this should be the default behaviour, and it isn't the Python way.

Likewise for enums from different enumerations. By default they should
evaluate unequal, not raise an exemption.


-- 
Steven.




More information about the Python-list mailing list