Hm, if people really want to write something like
color = enum(RED, WHITE, BLUE)
that might still be true, but given that it's likely going to look a little more like a class definition, this doesn't look so bad, and certainly doesn't violate DRY (though it's somewhat verbose):
class color(enum): RED = value() WHITE = value() BLUE = value()
The Python 3 metaclass can observe the order in which the values are defined easily by setting the class dict to an OrderdDict.
Even though I agree that enums lend themselves nicely to "class"-y syntax, the example you provide shows exactly why sticking to existing syntax makes use bend over backwards. Because 'color' is really not a class. And I don't want to explicitly say it's both a class and it subclasses something called 'enum'. And I don't want to specify values when I don't need values. All I really want is: enum color: RED WHITE BLUE Or shorter: enum color: RED, WHITE, BLUE Would adding a new "enum" keyword in Python 3.4 *really* meet that much resistance? ISTM built-in, standard, enums have been on the wishlist of Python developers for a long time. Eli