[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Apr 23 16:22:40 CEST 2013


On Tue, Apr 23, 2013 at 11:44 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

I'm having a problem with the proposed implementation. I haven't found any mention of it, so apologies if this has already been discussed:

from flufl.enum import * class C(Enum): ... a = 1 ... b = 2 ... C.a.class <class 'flufl.enum.enum.EnumValue'> isinstance(C.a, C) False isinstance(C(1), C) False It would really be better if instances were actual instances of the class, IMO.

Looking at the source (https://bazaar.launchpad.net/~barry/flufl.enum/trunk/view/head:/flufl/enum/_enum.py), I'm not seeing any fundamental technical issues with merging the Enum and EnumValue class definitions, and then using "cls" where the metaclass code currently uses "cls.value_factory" (even for the backwards compatible variant, the 2v3 metaclass issue isn't a problem, you can just define a _BaseEnum class with the right metaclass using the 2 & 3 compatible notation and inherit from that in a normal class definition)

However, there's one non-technical aspect of such a merger which does concern me, which is the fact that you would lose the distinct docstrings for the class and the values:

class C(flufl.enum.Enum): ... "My enum" ... a = 1 ... print(C.doc) My enum print(type(C.a).doc) Class to represent an enumeration value.

EnumValue('Color', 'red', 12) prints as 'Color.red' and can be converted
to the integer 12.

So I'm not sure the PEP has made the wrong choice here, but I agree the point is at least worth mentioning.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia



More information about the Python-Dev mailing list