On 02/26/2013 12:52 PM, Tim Delaney wrote:
On 27 February 2013 01:50, Terry Reedy <tjre...@udel.edu 
<mailto:tjre...@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~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to