On Thu, Jul 28, 2011 at 9:11 PM, 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).
ISTM a NamedValue could be either a copy of the original value or a wrapper around the original. Examples of the former include Nick's recipe and Barry's flufl.enum asint branch. Examples of the latter include the flufl.enum trunk. The copy version requires making the copy, which is less convenient if the value's type needs more than the instance to make a copy. The wrapper version probably wouldn't work well as a drop-in replacement for the original value. So if a NamedValue were to make it into the stdlib, which would it be? Does NamedValue add much value if not coupled with grouping? -eric p.s. FWIW I think Nick's recipe for NamedValue is the right approach for the copied-value model.
--Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas