[Python-Dev] def ... decorate

[Josiah Carlson]

I've kept my nose out of the decorator discussion, but I thought I would
give my opinion on this one...


> On Fri, 13 Aug 2004, Skip Montanaro wrote:
> 
> >with
> >
> >    def p_statement_expr:
> >        staticmethod
> >        grammarrule('statement : expression')
> >        version("Added in 2.4")
> >        deprecatedmethod
> >        type_(None)
> >    decorate (self, p):
> >        """docstring here"""
> >        print p[1]
> 
> Bingo!

Oh god no.


> Just replace decorate with "from" and the nice syntax is found:
> 
>     def f:
>         staticmethod
>         grammarrule('statement : expression')
>         version("Added in 2.4")
>         deprecatedmethod
>         type_(None)
>     from self, p:
>         """docstring here"""
>         print p[1]

Gah, the horror.


>  + doesn't surprise Python programmer, because it is like try-except, etc

It surprises anyone who expects the function signature immediately after
the name.

>  + reads a natural language (with implicit "with"  after "f")

But it is so radically different from current definitions that it breaks
current understanding about the language.  It also requires people to
learn two significantly different semantics for defining a function. 
The good proposals (IMO) keep the function name and signature unchanged.

So let us read this "natural language" (my interpretation of the syntax
given above):

define f as a staticmethod... from the arguments self and p with
function body...  Not bad, though I don't like the visual aesthetics.

>  + doesn't require any new keywords or symbols and "prefix" operators

Prefix operators don't seem that bad to me, nor to Guido (who offered
them in the first place), nor to the dozen+ others who have stated that
"@, !, %, *, -, +, | or & is cool".

As for keywords, there has been an offered solution; the use of a future
import.  Similar to the way yield was used in 2.3.

From is an import semantic, not function definition.  Overloading 'from'
does remove the necessity of a new keyword, but so does the use of the
symbols previously offered.

>  + is explicit about transformation
>  + no additional indentation

Ahh, but you indent the block of decorators before the function
definition must /always/ be read in order to figure out . While this has
been done before (try, except, finally)

>  - grepping for defs now require more effort, so probably second name should
>    be allowed after "from" or exactly this.
> 
> As a variant, docstring could be moved to the upper part.
> 
> I'd also liked being able to write:
> 
>    def f:
>         staticmethod; grammarrule('statement : expression')
>         version("Added in 2.4");  deprecatedmethod;  type_(None)
>    from x, y:
>       pass #...
> 
> and:
> 
>   def f: staticmethod
>   from x, y: return x+y

Yikes.


If there were voting, I'd like to put my vote in for:

@deco
def fun(arg1):
    #body

or

def fun(arg1):
    @deco
    #body

...with a preference towards the second one, and a slight prefence
toward some other symbol than @ (for compatibility reasons).  |, &, ! are
all aesthetically pleasing to me, in that order.

Reading the second one:
define fun with arguments arg decorated with deco and body...

To me it reads better than the three syntaxes offered by Skip and Roman
this morning.

 - Josiah