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! Cheers, -Barry