decorators as a special case of an @ operator?

[Peter Hansen]

Dan Christensen wrote:

> I wonder what people think of the following crazy idea, which has two
> parts.
> 
> 1) Allow anonymous multi-line functions.  For definiteness, I'll use
>    the following syntax, but lambda or something else could be used
>    too:
> 
>    f = def (a,b,c):
>          d = a*b
>          return d + c

I think this is identical to the following code, isn't it?

     def f(a, b, c):
         d = a * b
         return d + c

[...]
> Presto, you have decorators:
> 
> f = decorator1 @
>     decorator2 @
>     def (a,b,c):
>         d = a*b
>         return d + c
> 
> And the function name is at the top, like some people prefer.

I think if we asked them, they would clarify that it is not
the name *alone* which is important, but the *definition*.
Roughly the code that says this:

    i-am-defining-a-function this-is-the-name other-stuff:

I believe those of us who prefer to see the name first really
prefer to see something we might call the _definition_ (and
"def" is well-named here) which includes a sign that we are
defining a function, very near the name, and preferably with
the argument list also very close (since it is generally quite
important to a reader).  Nothing should be more important than
the name, so it should be first, then the arguments and other
meta stuff, then the body.  Languages like C which put the
return types first are unfortunate in that the return type is
not as important as the name, yet usually obscures it.  (I
used to write the return type on the previous line, sometimes
indented once, to avoid this problem, but that's still not
the best solution.)

> - To avoid trailing backslashes, the parser would have to
>   automatically continue to the next line when a line ends in @.

Sounds like another special case, as I'm not sure Python does
this for anything right now except when there are matched
opening and closing symbols.

-Peter