Features Download
From: Ethan Furman <ethan-gcWI5d7PMXnvaiG9KC9N7Q <at> public.gmane.org>
Subject: Re: PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library
Newsgroups: gmane.comp.python.ideas
Date: Tuesday 12th March 2013 22:16:40 UTC (over 4 years ago)
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?

CD: 3ms