[Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses) (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Jun 5 12:25:19 CEST 2012

On Tue, Jun 5, 2012 at 7:11 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

On 5 Jun 2012, at 08:53, Nick Coghlan wrote:

[snip...]

Now, one minor annoyance with current class decorators is that they're not inherited. This is sometimes what you want, but sometimes you would prefer to automatically decorate all subclasses as well. Currently, that means writing a custom metaclass to automatically apply the decorators. This has all the problems you have noted with composability. It seems then, that a potentially clean solution may be found by adding a dynamic class decoration hook. As a quick sketch of such a scheme, add the following step to the class creation process (between the current class creation process, but before the execution of lexical decorators):  for mrocls in cls.mro():  decorators = mrocls.dict.get("decorators", ())  for deco in reversed(decorators):  cls = deco(cls) Would such a dynamic class decoration hook meet your use case? Such a hook has use cases (specifically involving decorator inheritance) that don't require the use of sys.getframes(), so is far more likely to achieve the necessary level of consensus. As a specific example, the unittest module could use it to provide test parameterisation without needing a custom metaclass. Heh, you're effectively restoring the old Python 2 metaclass machinery with a slightly-less-esoteric mechanism. That aside I really like it.

Yup, writing a PEP now - I'm mostly interested in the inheritance aspects, but providing PJE with a way to get the effect he wants without monkeypatching undocumented builtins at runtime and effectively forking CPython's runtime behaviour is a useful bonus.

Metaclasses do have a problem with composition and lexical decorators don't play nicely with inheritance, but a dynamic decorator system modelled to some degree on the old metaclass mechanics could fill the gap nicely.

Cheers, Nick.

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

More information about the Python-Dev mailing list