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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4