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

[Stephen J. Turnbull]

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.