elements of decorator syntax suggestions

[Bengt Richter]

On Sat, 7 Aug 2004 04:02:36 +1000, Anthony Baxter <anthonybaxter at 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 at 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