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

Ethan Furman ethan at stoneleaf.us
Tue Feb 26 22:55:57 CET 2013

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

More information about the Python-Dev mailing list