[Python-ideas] Enums

[Eric Snow]

On Thu, Jul 28, 2011 at 9:11 PM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Jul 28, 2011 at 5:46 PM, Michael Foord <fuzzyman at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>