On Tue, Apr 23, 2013 at 11:44 PM, Antoine Pitrou <solip...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
