PEP 354: Enumerations in Python

[Stefan Rank]

on 28.02.2006 12:14 Carl Banks said the following:
[snip]
> 
>>> It's a pretty weak case to have a dedicated builtin to prevent
>>> duplicates in something that changes maybe once a month, as enums tend
>>> to change rather slowly.  (At least, that's the way enums in other
>>> languages are used, and the design you present here seems to suggest
>>> you intend to use them that way as well.)  And frankly, a unit test or
>>> assertion could check this.
>> [snip]
>>
>> I don't understand what you mean by 'change rather slowly'?
> 
> Construct data structure on-the-fly from an XML file edited by multiple
> people every day  = changes rather quickly
> 
> Construct data structure from a Python file that was last edited a year
> and a half ago = changes rather slowly
> 
> Typically, enums fall into the latter category.  You set the enum
> values, and then pretty much leave them alone, adding new values only
> occasionally.  (Come on, how often do the days of the week change?)
> All I was saying is, changes to the enum values are infrequent enough
> that having a special type just to make sure there are no duplicates is
> a waste.  The only justification for a built-in enum is the other stuff
> you mentioned.

agreed

>> One thing that is probably missing to allow this, is a enum-set-creation
>> with the | operator::
>>
>>    Weekdays = enum('mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun')
>>    daysihate = Weekdays.mon | Weekdays.thu
>>
>> (and this discussion needs to move to python-dev ?)
> 
> What's wrong with set((Weekdays.mon,Weekdays.thu))?  Explicit is better
> than implicit.

agreed again.
the | idea would only be for (interface) backwards compatibility.

>> As for the metaclass versions: For myself, the above version feels more
>> natural and straightforward (in the same way as the PEP author describes
>> it), though I understand the subclassing ideas.
>>
>> But are there use cases for subclassing, that aren't better served with
>> a new enum or something homegrown?
>> Can C++/Pascal/Java enums be subclassed?
> 
> In C++, enum is a type but not a class.  Same thing with Ada.  Java
> didn't have enums last time I checked.  Don't know about Pascal.

Was more of a question for subclassing use cases in other languages.
BTW Java has an enum now, which cannot be subclassed either AFAIK. And 
it's the same for (Delphi) Pascal.

> I
> didn't care too much about subclassing; I just thought different enum
> constant that couldn't (or, rather, oughtn't) be compared probably
> should be instances of a separate class.  It doesn't matter much,
> though.
> Should something like this work:
> 
> day = Weekdays.mon
> isinstance(day,Weekdays)
> 
> ?

I think in the PyPI package `type(Weekdays)` is `Enum` and 
`type(Weekdays.mon)` is `EnumValue`, so this would not work.
But membership testing `if day in Weekdays: ...` could do the same, and 
type-checking for enum values `isinstance(day, EnumValue)` would work 
(might be unpythonic though).

In the cookbook recipe `enum('..')` is a function and constructs two new 
types on the fly, so the values of two different enums would be of a 
different type, but you would not be able to name it easily...

cheers