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

[Ethan Furman]

On 03/12/2013 02:31 PM, Alex Stewart wrote:
> I haven't yet had a chance to read the proposed PEP, but based on the discussions I'm seeing, I have to admit I'm a
> little disappointed that I thought we had already managed to come together with a pretty common list of properties that
> we all agreed on for enum-like things in Python,

Sadly, no.  There seems to be two basic camps:  those that think an enum should be valueless, and have nothing to do 
with an integer besides using it to select the appropriate enumerator (that just looks strange -- I hope you're right 
Stephen!); and those for whom the integer is an integral part of the enumeration, whether for sorting, comparing, 
selecting an index, or whatever.

The critical aspect of using or not using an integer as the base type is: what happens when an enumerator from one class 
is compared to an enumerator from another class?  If the base type is int and they both have the same value, they'll be 
equal -- so much for type safety; if the base type is object, they won't be equal, but then you lose your easy to use 
int aspect, your sorting, etc.

Worse, if you have the base type be an int, but check for enumeration membership such that Color.red == 1 == 
Fruit.apple, but Color.red != Fruit.apple, you open a big can of worms because you just broke equality transitivity (or 
whatever it's called).  We don't want that.


> FYI, I have actually been working on a newer version of my enum implementation which includes support for compound enums
> (i.e. "oring" enum values together), and I believe covers almost all of the properties that I've heard people express a
> desire for on this list, and avoids most of the things people seem to have major issues with, so I would be interested
> to know if people actually have problems with it.  I'll see if I can get it cleaned up a bit and up on github in the
> next day or two so folks at least have an idea of how I've been looking at this stuff and can comment on what they think..

Looking forward to it.


> Regarding the issue of bitmask-enums, I do agree that they are common enough in various APIs that it is important that
> we be able to support them easily. /However,/ I have yet to see how or why they are actually different than int-enums in
> any practical way.  I don't see why we need to treat them as a different category at all and I see no value in doing so.
>   They're all just//int-enums.  Problem solved.

What you gain with a dedicated BitMask is better reprs -- the same thing you gain with an enum, after all.  Plus, with a 
standard enum you're using every number, but with a BitMask you are skipping most of them.

--> class Color(Enum):
...     black = 0
...     red   = 1
...     green = 2
...     blue  = 3
...     pink  = 4

--> Color.red | Color.green
# what do we see?  Color.blue? Color.red|green?

--> Color.blue | Color.pink
# and what here?  7? Color.blue|Color.pink?

--
~Ethan~