On Jul 25, 2011, at 07:43 PM, Michael Foord wrote:
On 25 July 2011 18:34, Barry Warsaw <barry@python.org> wrote:
I'm not sure it would be a good idea to do a mass mechanical substitution in the stdlib, so I'm not concerned that adopting enums would require a few int() calls to be added.
Well, if it isn't good enough for *us* then who is it good enough for? ;-)
I only meant that we have a tradition of not doing wholesale mechanical conversions when new features are added to the language or modules to the stdlib. This wouldn't be any different. :)
Some apis (for example those exported directly from C) can't work with something that isn't a real int.
That might be an important enough use case to sway me!
from flufl.enum import Enum class Thing(Enum): ... a = 1 ... b = 2 ... c = 4 ... Thing.a | Thing.b Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for |: 'EnumValue' and 'EnumValue'
Right. That's a consequence I think of EnumValues not being ints (and no other support for such operations being added.
Sure, I have no use case for ordering enums... I'm not sure I have a specific reason to *prevent* if that is extra work though.
Possibly so. I think my aversion to it is seeing things like >>> if Colors.red < Colors.blue: or even >>> if color < Colors.blue: Most enums (at least IME) are discrete objects that don't have a natural ordering. -Barry