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~
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