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

Ethan Furman ethan at stoneleaf.us
Tue Feb 26 17:03:40 CET 2013

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, ...)?

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:

-- Ethan

More information about the Python-Dev mailing list