On Tue, Jun 5, 2012 at 7:11 PM, Michael Foord <fuzzy...@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.
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
