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

[Xavier Morel]

On 5 juin 2012, at 14:24, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Tue, Jun 5, 2012 at 8:25 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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 mro_cls in cls.mro():
>>>>        decorators = mro_cls.__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.
> 
> PEP written and posted: http://www.python.org/dev/peps/pep-0422/
> More toy examples here:
> https://bitbucket.org/ncoghlan/misc/src/default/pep422.py
> 

Does it really make sense to meld decorators and inheritance so? With this, class "decorators" become way more than mere decorators and start straying quite far away from their function-based counterparts (which are not "inherited" when overriding methods but are statically applied instead)