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

Ethan Furman ethan at stoneleaf.us
Mon Feb 25 19:25:00 CET 2013

On 02/25/2013 10:05 AM, Barry Warsaw wrote:

On Feb 25, 2013, at 09:35 AM, Ethan Furman wrote:

>>> 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. Right, but my point is that if isinstance(Colors.green, int) then a reasonable interpretation is that enum values will compare equal against other ints. It seems weird to me that enum values are ints but aren't substitutable with ints (e.g. comparable against other ints including other subclasses of ints).

That is certainly a valid point. I will admit to being unhappy with the whole dict/set issue; I'm considering making my enums unhashable -- then if one wants them in a dict, one can take the string or int value and add it that way.

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. Maybe. I don't think a stdlib solution has to meet all needs. I think named values plus int-interoperable enums will solve almost all use cases.

Hey, I think I just had a light-bulb moment: have the enum implement index -- that will solve my use-case of using them for list indices.

Dumb question, but are flufl.enums ordered? That's also an important use case.

-- Ethan

More information about the Python-Dev mailing list