(original) (raw)

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!