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

Stephen J. Turnbull stephen at xemacs.org
Wed Feb 27 04:16:52 CET 2013

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.

More information about the Python-Dev mailing list