[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/26/2013 01:29 AM, Stephen J. Turnbull wrote:
> Ethan Furman writes:
>> Stephen J. Turnbull wrote:
>>> Note that in both counting and listing the object of the
>>> operation is not an element.  It is a set, and set membership is
>>> the most important aspect of the elements for that purpose.
>>
>> No, it isn't.  It may be in some cases.
>
> I'm referring only to the dictionary definitions you quote.

Ah, okay.  Although, going with the first definition -- "ascertain the number of" -- I still maintain that the number is 
equally important, otherwise it could be a simple set.


> It really sounds to me like your use case (and even more so,
> Antoine's) would be perfectly well-served by a named constant class
> that doesn't know anything about enumerability.

My enumeration needs tend to be sequential; hence, well served by a class that easily binds names and sequential natural 
numbers together.


>> My enums even respect it to the point of not comparing equal to
>> different enum sets.  But, quite frankly, it's the enum's ability
>> to let me use a name to mean a number that is the most
>> important. And the most important thing for the Enum class is to
>> assign those numbers for me as automatically as possible.
>
> But "mean a number" and "assigned automatically" are close to mutually
> exclusive (except that "as possible" gives you a lot of wiggle room).

My main "as possible" case is when a number (or short range of numbers) is reserved for future use; being able to easily 
skip to the next meaningful number is a Good Thing.


> That is, if by "name means number" you imply that the numbers have
> semantics (as in Antoine's HTTP status code example), you care what
> the numbers are, and they can't be assigned automatically.

For the status code example I would probably manually assign all the numbers, since there are so few and the gaps 
between so large.

But for my use, which is mainly as list indices, all I have to do is list the names in the correct order -- so I do care 
what value they have, and they can be assigned automatically.


> OTOH, if the numbers are assigned very automatically (ie, completely
> implicitly), I have trouble with coming up with a use case where
> ability to use integer arithmetic (including comparisons other than
> equality and set membership) on them *by default* is anything but a
> trap.  Eg, with a Likert scale for preference[1], I *do* want to order
> them, but (at least when I'm teaching statistics) I *really* *don't*
> want them added and subtracted without thinking about exactly what the
> operation means.

Every time I do arithmetic with True/False I have to think about what's going on;  I see no difference between that and 
doing arithmetic with Color.red.


> And if you really need arithmetic and automatic assignment is good
> enough, what's wrong with their ordinary names (ie, 1, 2, 3, ...)?
> <wink/>

Because in one file CITY is in column 13, in another it's in column 15, in a third it's in column 7.  Much better 
(easier, safer, more readable) to get the assignment done _once_ and then use CITY everywhere else.  And an easy to use 
int-based Enum class makes that easy.  (And before you ask, yes, I need all the other columns as well.)


> Footnotes:
> [1]  A qualitative expression of strength of feeling ("hate" = 1,
> "dislike" = 2, "indifferent" = 3, "like" = 4, "love" = 5).

I'm beginning to see why enums as a class has not yet been added to Python.  We don't want to complicate the language 
with too many choices, yet there is no One Obvious Enum to fit the wide variety of use-cases:

   - named int enums  (http status codes)
   - named str enums  (tkinter options)
   - named bitmask enums  (file-type options)
   - named valueless enums  (any random set of names)
   - named valueless-yet-orderable enums  (any not-so-random set of names ;)

--
~Ethan~