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

[Ethan Furman]

On 02/25/2013 06:45 AM, Eli Bendersky wrote:
>
>         2) When you do, wrapping the item in int() doesn't seem too bad to me.
>
>
>     If it was just once or twice, sure, but I use them as names for ints, which means I use them as ints, which means I
>     would have a boat load of int() calls.
>
>
> Personally I don't see "name for ints" as being the main use case for enums.

I must admit I find it mildly amusing (but a lot frustrating) that we are talk about /enumerations/ not needing to be 
based on ints.  Checking out Merrian-Webster gives this:

Definition of ENUMERATE
1
: to ascertain the number of : count
2
: to specify one after another : list

Python even has an enumerate function, and what does it do?  Gives us an int to associate with some item in an iterator.

Now we're talking about adding an official Enum class, but the int portion is unnecessary and a pain to use?

>  For preparing the draft PEP I ran through
> some stdlib, Twisted and personal code and there are *tons* of places that just need a simple enum for some sort of
> "state", meaningful return value, or similar. That's really where you need enums the most, and really where their values
> don't matter.

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.


> I prefer to have a good solution to one problem than a poorer solution that tries to cover two unrelated problems. For
> "names for ints", Nick's named value proposal seems more relevant, but why mix the two together?

Again:

Definition of ENUMERATE
1
: to ascertain the number of : count
2
: to specify one after another : list

--
~Ethan~