Re: elements of decorator syntax suggestions

From: Bengt Richter (bokr_at_oz.net)
Date: 08/07/04 

Date: 7 Aug 2004 00:13:50 GMT

On Sat, 7 Aug 2004 04:02:36 +1000, Anthony Baxter <anthonybaxter@gmail.com> wrote:
>This is an excellent list! Thanks for doing it. I've made a couple of notes
>inline about the particular points.
+1 on the info format of the post

>
>On 6 Aug 2004 10:19:21 -0700, Steven Bethard <steven.bethard@gmail.com> wrote:
>> I think one of the biggest reasons we're having such problems coming
>> to any agreement on decorator syntax is that each proposal makes a
>> number of syntax decisions, not just one. For decorators, I see the
>> following decisions that must be made:
>>
>> 1) Indicator
>> Proposals differ on how some sort of indicator of "decoratorhood" is
>> use. These include:
>> * none (e.g. just the list, as in the "list-after-def" suggestion)
>> * the '@' character
>> * a new keyword (with, using, decorate, etc.)
>
what about a builtin name? or does that count as a keyword?

>This is the biggy, it seems. Current (as of a couple of hours ago)
>discussions on python-dev are discussing other alternatives instead
>of @, that will hopefully make it easier for IPython or Leo to cope
>for now (but note that in the future, some other use for @ might be
>found, so anyone relying on it at the moment might want to think
>about that). One current suggestion is to use the | character, instead.
>
>> 2) Location
>> Proposals also differ on exactly where the decorator declaration
>> should be made. These include:
>> * before def
>
>Short of someone producing a _very_ strong argument in favour of
>another form, this is almost certainly going to be the choice.
>
>> * between def and function name
>
>Breaks too many tools, as well as stupid humans who are used to seeing
>def functionname.
>
>> * between function name and argument list
>
>I'm not sure that this was ever popular, with anyone ;)
>
>> * between argument list and colon
>
>Guido's ruled this out (see previous posts, I put a link to his post
>outlining why.
>
>> * after colon (first line in body)
>
>A problem here is interaction with docstrings?
>
>
>> 3) List notation
>> As I understand it, it's already decided that any implementation of
>> decorators must allow for a list of decorators to be applied. So
>> proposals that might be accepted must explain how this can be done.
>> The options I've seen:
>> * one per line (as currently)
>
>There's some confusion as to how the one-per-line thing is ordered. I find
>it quite obvious, but I've been playing with this for a week now, so it might
>just be that I know the answer now. Simply -
>
>@decA
>@decB
>@decC
>def func():
>
>is equivalent to
>
>func = decA(decB(decC(func)))
>
Looks to me like the semantics is

    __magic_internal_list.append(decA)
    __magic_internal_list.append(decB)
    __magic_internal_list.append(decC)
    def func(): pass
    while _magic_internal_list: func = __magic_internal_list.pop()(func)

why not go with a little sugar like
    __builtins__.decorate = __magic_internal_list.append

and then
    decorate(decA)
    decorate(decB)
    decorate(decC)
    def func(): pass
    # (automatic trigger of the while statement above, after the def)

Of course, I think more interesting things can be done along with that bare minimum,
but even this minimal implementation at least avoids such a narrow commitment for '@'.
BTW, even if __magic_internal_list were per-thread, wouldn't one need guidelines at
least for writing wrappers safely? What does current @decorator do?

>
>An excellent list! If you don't mind, I might steal this format for the PEP.
>It allows for a lot more alternatives to be covered off in a smaller space
>(since many proposals are minor variations on an existing proposal, and
>share the same problems).
+1 on that ;-)

Regards,
Bengt Richter

Relevant Pages

  • Re: Docorator Disected
    ... > def get_function(function): # Get func object off stack ... To understand decorator chains it is very helpfull to accept the ... def default: ... The function mul defines the inner functions default, ...
    (comp.lang.python)
  • Re: Docorator Disected
    ... > def get_function(function): # Get func object off stack ... def decorator: ... you will see that the comment "decorator ... Decorator feature is a metaprogramming feature. ...
    (comp.lang.python)
  • Re: execute a function before and after any method of a parent class
    ... After reading this article by M. Simionato http://www.phyast.pitt.edu/~micheles/python/documentation.html you should be able to write a decorator to make any method into a "sandwich". ... def bar: ... if isinstance(item, func): ...
    (comp.lang.python)
  • Re: Emulate @classmethod using decorator and descriptor
    ... if klass is None: ... def wrapped: ... and seems that a function decorator works as follows: ... print 'func' ...
    (comp.lang.python)
  • Re: Getting rid of "self."
    ... def __init__: ... > basis of information available at the time the decorator executes. ... I am content with declaring them like the selfless ... foo = _foo ...
    (comp.lang.python)