On Jan 30, 2013, at 03:16 PM, Michael Foord wrote:

>Being an int subclass (and possibly optionally a strs subclass) is a
>requirement if any adopted Enum is to be used *within* the standard library
>in places where integers are currently used as "poor man's enums". I also
>don't *think* flufl.enum supports flag enums (ones that can be OR'd
>together), right?

Sure, it does because you have to be explicit about the enum int value to
assign the item.  This doesn't bother me because the syntax is clear, I almost
always want an explicit int value anyway, inheritance is supported, and as you
comment, flag values are (mostly) easy to support.

class Colors(Enum):
    red = 1
    green = 2
    blue = 3

class MoreColors(Colors):
    cyan = 4
    magenta = 5
    # chartreuse = 2 would be an error

class Flags(Enum):
    beautiful = 1
    fast = 2
    elegant = 4
    wonderful = 8


Now, it's true that because Flags.fast is not an int, it must be explicitly
converted to an int, e.g. `int(Flags.fast)`.  That doesn't bother me.

What does bother me is that Enum doesn't support automatic conversion to int
for OR and AND, so you have to do this:

>>> int(Flags.fast) | int(Flags.elegant)
6

That should be easy enough to fix by adding the appropriate operators so that
you could do:

>>> Flags.fast | Flags.elegant
6

Returning an int from such operations is the only sensible interpretation.

https://bugs.launchpad.net/flufl.enum/+bug/1110501

As far as autonumbering goes, I think we could support that in Python 3.3+,
though I don't have any brilliant ideas on syntax.  A couple of suggestions
are in this bug:

https://bugs.launchpad.net/flufl.enum/+bug/1110507

e.g

class Colors(Enum):
    red = None
    green = None
    blue = None

or

from flufl.enum import Enum, auto
class Colors(Enum):
    red = auto
    green = auto
    blue = auto

I'm definitely open to suggestions here!