[Python-Dev] Enum: subclassing?
Georg Brandl
g.brandl at gmx.net
Wed May 1 23:44:03 CEST 2013
Am 01.05.2013 23:19, schrieb Eli Bendersky:
> It's a common pattern to do this with a base class rather than a
> mixin, though, and I think the rule "only allow subclassing empty
> enums" makes a lot of sense.
>
>
> I see your point (and Antoine's example in the next email is good), but my
> concern is that this is a TIMTOWTDI thing, since the same can be achieved with
> mixins. Specifically, Antoine's example
> becomes:
>
> class IETFStatusCode:
> @classmethod
> def from_statusline(cls, line):
> return cls(int(line.split()[0]))
>
> class HTTPStatusCode(int, IETFStatusCode, Enum):
> NOT_FOUND = 404
>
> class SIPStatusCode(int, IETFStatusCode, Enum):
> RINGING = 180
Now try it like this:
class SIPStatusCode(IETFStatusCode, int, Enum):
RINGING = 180
and you'll get
Traceback (most recent call last):
File "/home/gbr/devel/ref435/ref435.py", line 84, in __new__
enum_item = obj_type.__new__(result, value)
TypeError: object.__new__(SIPStatusCode) is not safe, use int.__new__()
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "ex.py", line 11, in <module>
class SIPStatusCode(IETFStatusCode, int, Enum):
File "/home/gbr/devel/ref435/ref435.py", line 86, in __new__
raise EnumError(*exc.args) from None
TypeError: exception causes must derive from BaseException
> Same thing, while keeping the stdlib API cleaner and more minimal. Cleaner
> because "no subclassing" is a simpler, more explicit, and easier to understand
> rule than "no subclassing unless base class is devoid of enumeration values".
> And because we can no longer say "Enum classes are final", which is a relatively
> familiar and understood semantic.
I fear the "you can use mixins provided you put them in the right spot in the
base classes list" rule is not much simpler than the "no subclassing of enums
with values" rule.
Georg
More information about the Python-Dev
mailing list