Ethan Furman writes: > 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.
Of course "number" is central to counting -- but you can count a set of objects that have no numerical value. You can also count objects with numerical values that cannot be a count for that set: fractions, negative integers, etc. There's no necessary connection between the integers used for counting, and those that are values of the things counted. > 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. OK, that sounds like a valid use case to me. I don't mean to deprecate it, I just don't understand it because I'd never do that myself -- in all the cases where I care about the names and there's a variable order, the names are in the data. Eg, a CSV file with a header row. So I read them and need to create an inverse mapping. And in general, I need a string->index mapping for UI. So using an enum so I can hard-code column names doesn't help me much -- I'm doing a lot of string manipulation anyway. Worse for me, most of the applications I have, I'd like the enumerator identifiers to be both string-valued and int-valued: the int used to index into Python sequences, and the string used in formatting SQL. > 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. The pedagogical problem is that in a Likert scale "have to think" is a prescriptive requirement that students and even experienced researchers ignore all the time. They easily think of "hate" and "like" as the numbers 1 and 4, and they want to take averages across people. But that doesn't make sense if you examine behavior carefully: even though everybody agrees on order, the size of the steps and origin are different for different people. So I want to make it a logical constraint enforced by Enum, to be relaxed only if the user signs a no-damages release. I don't have an objection to making that easy by providing derived Enum types that have int or string values, or to a subclass of ordered Enums. Just that the base Enum type should be a collection of Python identifiers that you can't do much with except compare for identity, and operations would be added only with some kind of explicit indication like IntEnum, OrderedEnum, etc. _______________________________________________ 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
