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

[Ethan Furman]

On 02/26/2013 12:52 PM, Tim Delaney wrote:
> On 27 February 2013 01:50, Terry Reedy <tjreedy at udel.edu <mailto:tjreedy at udel.edu>> wrote:
>> We should NOT knowingly re-introduce the same problem again! If color and animal are isolated from each other, they
>> should each be isolated from everything, including int.
>
> FWIW the only reason I made my enums int-based (and comparable with ints) was because I read somewhere that Guido had
> said that any stdlib enum would have to be an int subclass.

I recall that as well.


> I have no problems with having int-like enums that:
>
> 1. Are not int subclasses;
>
> 2. Do not compare equal with ints unless explicitly converted.
>
> I do think an int-like enum should implement both __int__ and __index__.


I think it will take more than one type of Enum to handle the myriad needs.

1) Default enumeration: valueless, unordered:

     class BreakfastMeat(Enum):
         eggs = 'from a chicken'
         ham = 'from a pig'
         spam = 'from a ... um ... '

2) non-valued, yet ordered:

     class DaysOfWeek(OrderedEnum):
         sunday = 'last day of weekend'
         monday = 'is it the 13th??'
         tuesday = 'not as bad as monday'
         wednesday = 'halfway through!'
         thursday = 'almost there...'
         friday = 'thank goodness'
         saturday = 'sleeping in!'

3) bitmask: sub-classes int, but not directly interactable (except for shifts)

     class DbfFieldOptions(BitMaskEnum):
         binary = 'no unicode translation'
         nullable = 'can store None'
         system = 'internal use only'

4) named string (based on str, basically a named constant)

     class TkGeometry(StrEnum):
         top = north = 'top'
         bottom = south = 'bottom'
         left = west = 'left'
         right = east = 'right'

5) named integer (based on int, basically a named constant)

     class RowLabels(IntEnum):
         name = 0
         address = 1
         city = 2
         state = 3
         zip = 4


In the first three examples the data in quotes is the doc string; in examples 4 and 5 the RHS is the actual value 
assigned.  For that matter, 4 and 5 could be compacted into a NamedValue class, allowing whatever type is needed (since 
set membership is not restricted anyway):

     class Constants(NamedValues):
         top = 'top', 'top, or north, edge'
         bottom = 'bottom', 'bottom, or south, edge'
         pi = 3.14159, "circle's circumference divided by it's radius"
         lucky = 7, 'come on, 7!'
         unlucky = 2, 'snake eyes!'

That would get us to three enum classes and one namedvalue class, and should cover 99% of the use cases out there.

Does anyone still reading this thread have a use case not covered by the above?

--
~Ethan~