Home Original page

[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

Ethan Furman ethan at stoneleaf.us
Mon Feb 25 18:35:58 CET 2013 
On 02/25/2013 08:37 AM, Barry Warsaw wrote:
> On Feb 25, 2013, at 07:12 AM, Ethan Furman wrote:
>
>> And if, in those places, the enums were based on ints (or strings), would it
>> hurt you?  Because in the places where I, as well as many others, use enums
>> we *need* the int portion; and having to wrap the enum in an int() call is
>> seven extra keystrokes (minor) and a heap of visual clutter (major),
>> destroying any value the enum was supposed to have.
>
> Yes, I think enum values inheriting from int (or string) would hurt.
>
> First, as your question implies, which is it?  int or str?  Some people want
> int some want str.  It can't be both, and I don't think we need two enum
> types.

I can see enums of at least three different types being useful: int, str, and bitmask; a valueless enum would be a fourth.


> It's a deeper question though, because if enum values inherited from int, then
> people would expect things like ``Colors.red == 1`` to work.  Maybe you think
> that doesn't look so bad, but that also implies:

I do expect that to work.


>      >>> Colors = make('Colors', 'red green blue'.split())
>      >>> Animals = make('Animals', 'ant bee cat'.split())
>      >>> Colors.green == Animals.bee

But this I don't, and in both mine, Ted's, and Alex's versions enums from different groups do not compare equal, 
regardless of the underlying value.  Of course, this does have the potential problem of `green == 1 == bee` but not 
`green == bee` which would be a problem with set and dicts -- but I'm the only one who has brought up that issue.


> I get that you think wrapping the value in int() is ugly.  I have a compromise
> that you might find acceptable.  EnumValues already have .enum and .name
> attributes, to give you the value's class and string name respectively.  It
> would be trivial to add a .int attribute to return the value.
>
> Thus if you want the int value, it would be easy enough to say
> ``Colors.green.int`` or ``Animals.bee.int``

Well, it certainly isn't as ugly, and isn't as hard on the wrists.  If your's is the package that makes it in the stdlib 
I would certainly appreciate the modification.

However, as I replied to Skip, I think a stdlib solution should meet many needs, and sometimes (often, for some people 
;) those needs will be better served by an int-based or str-based enum.

--
~Ethan~
More information about the Python-Dev mailing list