[Python-Dev] backported Enum

[Jim J. Jewett]

(On June 19, 2013) Barry Warsaw wrote about porting mailman from
flufl.enum to the stdlib.enum:


> Switching from call syntax to getitem syntax for looking up an
> enum member by name, e.g.

>    -        delivery_mode = DeliveryMode(data['delivery_mode'])
>    +        delivery_mode = DeliveryMode[data['delivery_mode']]

> Switching from getitem syntax to call syntax for looking up an
> enum member by value, e.g.

>    -        return self._enum[value]
>    +        return self._enum(value)

> Interesting that these two were exactly opposite from flufl.enum.

Is there a reason why these were reversed?

I can sort of convince myself that it makes sense because dicts
work better with strings than with ints, but ... it seems like
such a minor win that I'm not sure it is worth backwards
incompatibility.  (Of course, I also don't know how much use
stdlib.enum has already gotten with the current syntax.)



> Switching from int() to .value to get the integer value of an
> enum member, e.g.

>    -    return (member.list_id, member.address.email, int(member.role))
>    +    return (member.list_id, member.address.email, member.role.value)

Is just this a style preference?

Using a .value attribute certainly makes sense, but I don't see it
mentioned in the PEP as even optional, let alone recommended.  If
you care that the value be specifically an int (as opposed to any
object), then a int constructor may be better.

> [Some additional changes that mean there will be *some* changes,
> which does reduce the pressure for backwards compatibility.] ...


> An unexpected difference is that failing name lookups raise a
> KeyError instead of a ValueError.

I could understand either, as well as AttributeError, since the
instance that would represent that value isn't a class attribute.

Looking at Enum creation, I think ValueError would be better than
TypeError for complaints about duplicate names.  Was TypeError
chosen because it should only happen during setup?

I would also not be shocked if some people expect failed value
lookups to raise an IndexError, though I expect they would
adapt if they get something else that makes sense.

Would it be wrong to create an EnumError that subclasses
(ValueError, KeyError, AttributeError) and to raise that
subclass from everything but _StealthProperty and _get_mixins?


-jJ

-- 

If there are still threading problems with my replies, please 
email me with details, so that I can try to resolve them.  -jJ