[Python-Dev] backported Enum (original) (raw)
Jim J. Jewett jimjjewett at gmail.com
Fri Jun 28 22:07:50 CEST 2013
- Previous message: [Python-Dev] backported Enum
- Next message: [Python-Dev] backported Enum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
(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.
- deliverymode = DeliveryMode(data['deliverymode']) + deliverymode = DeliveryMode[data['deliverymode']]
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.listid, member.address.email, int(member.role)) + return (member.listid, 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
- Previous message: [Python-Dev] backported Enum
- Next message: [Python-Dev] backported Enum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]