[Python-ideas] PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library

Ethan Furman ethan at stoneleaf.us
Mon Mar 11 18:25:11 CET 2013

On 03/11/2013 09:55 AM, Paul Moore wrote:
> On 11 March 2013 16:18, Ethan Furman <ethan at stoneleaf.us> wrote:
>> First, I offer my apologies to all who are still battle-weary from the last
>> flurry of enum threads.
> [...]
>> This new PEP proposes an enum module that handles all those use cases, and
>> makes it possible to handle others as well.
> One thing that is not discussed in the PEP (at least from my quick
> reading of it) is the issue of transitivity of equality

There are four types you can inherit from: Enum, BitMask, Sequence, and String.
Enum, BitMask, and String will not compare equal with integers, and Enum, BitMask
and Sequence will not compare equal with strings; in fact, Enum and Bitmask, not
being based on an existing data type, will not compare equal with anything that is
not in their own enumeration group or its superclass.  Sequences will
compare equal with ints, because they are ints;  they will also compare equal
against other Sequence enumerations, as they are also ints.  Same deal with
Strings and strs.  Those two are basically NamedValues in a fancy enum package.

> Personally, I find this behaviour unacceptable. The lack of a good way
> of dealing with this issue (I don't particularly like the "just use
> int()" or special value property approaches either) seems to be key to
> why people are failing to agree on an implementation...

Hopefully that's clearer now.

> At the very least, there should be a section in the PEP addressing the
> discussion over this.

I'll get it added (probably next weekend, when I make any other necessary
changes as well).

> The motivation section isn't particularly strong, either. There's
> nothing there that would persuade me to use enums. In general, the
> proposal seems geared mainly at people who *already* want to use
> enums, but for some reason aren't comfortable with using a 3rd party
> package. But maybe that just implies that I'm not part of the target
> audience for the feature, in which case fine (I don't have to use it,
> obviously...)

My main use case is an easy mapping from names to numbers, but that's not


More information about the Python-ideas mailing list