[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

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