[Python-Dev] def ... decorate

[Josiah Carlson]

> I understand that not everyone will like every idea and that in this
> particular arena it seems that no one idea is acceptable to everyone, but
> can we return to my proposal and discuss its pros and cons?  I didn't pick
> the example out of thin air.  I cast an existing example from c.l.py in this
> form (thus the function name and somewhat unusual collection of decorator
> names).  The only thing I added besides the syntax change was to identify
> where I thought the docstring should go.
> 
>     def p_statement_expr:
>         staticmethod
>         grammarrule('statement : expression')
>         version("Added in 2.4")
>         deprecatedmethod
>         type_(None)
>     decorate (self, p):
>         """docstring here"""
>         print p[1]
> 
> Roman Suzi seemed to like it, given his "Bingo!" remark, but felt
> immediately moved to alter it with no explanation.  Josiah replied to that
> with "Oh god no".  It went downhill from there, to the point where Raymond
> posted a sarcastic note about using reST and XML.  I don't know if Roman's
> immediate modification implies his "Bingo!" was just lukewarm.  I have no
> idea what Josiah was saying "Oh god no" to.

Mostly the separating the function name from the arguments.


>     * It doesn't put the cart before the horse by introducing the decorators
>       before the def.

Great.

>     * It doesn't add an extra level of indentation to the function body.

Great.

>     * It leaves '@' alone, implying that at some point in the future Guido
>       (if he so chooses) proclaim that "'@' will never be used in Python at
>       the start of a line, so it is free for external tools to use as a
>       markup character".

!|&-+* also leave the '@' alone.  I think that if it werent for '|'
being mistakable for I,l or 1, it would already have been chosen.


>     * It looks more like current Python block structure (at least to me)
>       than the @-syntax proposal.

Check my P.S. at the end.


> I understand that it has obvious weaknesses as well:
> 
>     * It separates the function name from its parameter list.  That does
>       allow us to avoid parsing ambiguities though.

Separating the argument list from the function name is enough to kill it
for me.


>     * It can't readily be extended to class definitions, though the demand
>       for that seems minor and mostly argued for symmetry reasons.

Why can't it be extended?

class decorated_class:
    decorators
decorate:  #or (subcls1, subcls2) before the colon with subclasses
    "docstring"
    body


Personally, I don't desire decorators for classes for symmetry reasons,
I desire it to replace metaclasses, at least in those things that I
could conceivably want metaclasses to do.


> One or more of those weaknesses may well be a show stopper.  There may be
> other pros and cons I'm missing.  That's fine, but can people please be
> specific in their criticism?  I purposely posted twice, once here and once
> on c.l.py, to avoid random smartass responses on c.l.py from leaking over to
> python-dev.  Little did I realize I need not have worried about that.

My major issue is that I think we should be making a small change to the
language.  I believe that any change that could be considered a large
change should be avoided.

Introducing an additional block structure to specify decorators seems to
be a large change.

Separating the name of a function from the arguments seems to be a large
change.

Other proposals attempt to indent function definitions inside decorators,
which is also a large change (which also destroy readability).


Let us try to keep the change small.  Sound reasonable?

 - Josiah

P.S.
One could make the claim that assigning directly to __slots__ and
__metaclass__ are a bit of magic that could have been avoided with
proper decorators (or even that metaclasses could have been avoided with
decorators).

@__metaclass__(metaclass)
@__slots__("slot1", "slot2")
class classname:
    #etc.

Heck, it almost looks like what we already have in Python when we do the
following...

class classname(object):
    @__metaclass__(metaclass)
    #or @metaclass_like_decorator
    @__slots__("slot1", "slot2")
    @__doc__("docstring")
    #etc.


Goodness, there's a syntax to rule them all.  Not only does it kind of
look like what we already have, but it is further extendable with other
__name__ decorators.

Choose any @ replacement if desireable.