[Datetime-SIG] Another round on error-checking

Chris Angelico rosuav at gmail.com
Tue Sep 1 06:03:46 CEST 2015


On Tue, Sep 1, 2015 at 12:59 PM, Tim Peters <tim.peters at gmail.com> wrote:
>> I was under the impression that such cases are to be considered
>> bugs.  I know it was a driving concern in the implementation of the enum
>> module.
>
> Sorry, I just had to laugh at the notion that enums _could_ be
> implemented in such a convoluted way that there'd ever be the
> slightest possibility of transitivity failing ;-)
>

Easy: you just declare that different enumerations are not
comparable,, but that all are comparable to their base type.

class Color(IntEnum):
    RED=1
    GREEN=2
    BLUE=3
class Permission(IntEnum):
    READ=1
    WRITE=2
    EXECUTE=3

What should Color.RED==Permission.READ give? True, because they're
both 1? False, because they're completely different things? TypeError,
because you can't logically compare colors and permissions?

If you allow that Color.RED==1 (which you need to if it's going to be
possible to backwardly-compatibly change raw numbers into an enum),
then transitivity demands that the otherwise-illogical comparison
above succeed, and be True. As a design decision, it could viably be
taken either way, but once taken, it has to be maintained forever.

ChrisA


More information about the Datetime-SIG mailing list