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~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4