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