On Fri, Jul 29, 2011 at 6:11 AM, Guido van Rossum <guido@python.org> wrote:
On Thu, Jul 28, 2011 at 5:46 PM, Michael Foord <fuzzyman@gmail.com> wrote:
I agree "named values" would get us *most* of the value, and would both be less contentious and provide a common building block for third party libraries to build interesting and perhaps esoteric uses on.
I *like* grouped named values (I think they make nice apis to read and use when used appropriately), but hey-ho.
These could be two separate features. Named values could be a building block for a built-in Enum type -- the named value would take care of the str() and repr(), while the Enum type would only have to take care of the nice syntax ("class Color(Enum): red = 1; ...") and just create a bunch of named values in the class scope. The metaclass would do something like "for key in classdict: classdict[key] = namedvalue(key, classdict[key])" (though it would probably have to skip certain keys).
The problem with named value is that: namedvalue(1, "red") Will give you are repr of "red". And you don't know whether it's TerminalColors.red or WebSafe.red or BuildbotState.red. And most of us will be too lazy to add group name or module name directly into the named value (partially because it's repeating yourself). So the big feature of flufl.enum is classname (call it group name) in repr and isinstance check. -- Paul