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~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to