[Python-ideas] PEP for enum library type?

[Rob Cliffe]

On 21/02/2013 23:24, Greg Ewing wrote:
> On 22/02/13 08:18, Alex Stewart wrote:
>> In non-Python code, typically enums have always been represented 
>> under the
>> covers as ints, and therefore must be passed back and forth as 
>> numbers. The
>> fact that they have an integer value, however, is purely an 
>> implementation
>> artifact.  It comes from the fact that C and some other languages 
>> don't have
> > a rich enough type system to properly make enums their own distinct 
> type
>
> I don't think that's true for all languages. For example, enums in
> Pascal are definitely distinct types from integers, yet the language
> explicitly assigns them ordinal values and defines an ordering for
> them. Wirth must have thought there was a benefit in doing that.
>
Not necessarily.  With respect to the great man, he may not have given 
the matter as much thought, or considered (or been interested in) as 
many use cases as the contributors to this thread have.
>> It doesn't seem
>> unreasonable, therefore, to define two different categories of enums: 
>> one that
>> has no concept of "value" (for pure-Python), and one which does have
>> associated values but all values have to be specified explicitly
>
> That sounds reasonable. However, I'm wondering if there isn't a
> third case: where you don't care about the values, but you do
> want them to have a defined ordering?
The same thought occurred to me, although I could not think of a use 
case on the spot.  But I think that there surely are such.
>
>>    1. Enum syntax should not be "too magic". (In particular, it's 
>> pretty clear
>>       at this point that creating new enums as a side-effect of name 
>> lookups
>>       (even as convenient as it does make the syntax) is ultimately 
>> not gonna fly)
>
>>    4. It shouldn't be necessary to quote enum names when defining 
>> them (since
>>       they won't be quoted when they're used)
>
> Satisfying both of these constraints without new syntax seems
> to be pretty much impossible. That seems to be the main
> sticking point in these discussions.
>
>> I want to check: Is this a valid summary of things?
>
> It looks pretty comprehensive to me!
>
Apart from the point about maybe wanting to order enums, I agree.  I 
think Alex is right when he says you want to create singleton enums that 
don't equate to anything else.  We don't think of RED, GREEN, BLUE as 
being identical with the ints 1,2,3, and so don't want our 
implementation of them to compare equal to those ints.
Rob Cliffe