On 5 juin 2012, at 14:24, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Tue, Jun 5, 2012 at 8:25 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> 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.
>
> 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)
_______________________________________________
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
