@decorators

[David Fraser]

daishi wrote:
> For what it's worth:
> 
> As far as I know, the proposed @decorator syntax will be the first
> time that two logical lines of python with the same indentation will
> not be independent of one another. Previously, when looking at:
> 
> 	some_python(code)
> 	and_some_more = stuff
> 
> there was no need to look at the the first line in order to know what
> the second line meant/did (and vice versa). It would seem that the
> cases when there are effects across multiple logical lines is captured
> in compound statements:
> 
> """
> Compound statements contain (groups of) other statements; they affect
> or control the execution of those other statements in some way.
> """ -Python Reference Manual
> 
> My understanding of decorators is that they fit this definition.
> One thing that I am not entirely clear about is whether decorators
> are intended to be a compound statement themselves, or whether they
> are meant to simply be extensions of current compound statements
> such as function definition (and class definitions?)
> 
> In either case, however, it seems that the following should apply:
> 
> """
> Each clause header begins with a uniquely identifying keyword and ends
> with a colon. A suite ... can be one or more indented statements on
> subsequent lines.
> """ -Python Reference Manual
> 
> In the first case where decorators form their own compound statement,
> this would seem to imply the basic layout of:
> 
> @decorator:
>     def foo():
>         pass
> 
> (Whether that uniquely identifying keyword for decorators happens to
> be spelled '@' is not important to me.)
> 
> In the second case where decorators are simply extensions of current
> compound statements, the current wording of the Python Reference
> Manual would seem to imply that for function definition the clause
> header must begin with 'def'. I.e., the decorator should not come
> before the def, and certainly not on a separate line. Beyond this,
> however, for me it is not particularly important whether the
> decorator comes before/after the function name/argument list, and
> how it is delimited.
> 
> I guess the basic point that I am trying to make is that what I find
> important is consistency with the basic visual layout of code promised
> (IMHO) by python. I believe that this promise is violated by the
> currently proposed decorator scheme.
> 
> d
> 
> PS: Although I believe the current view of the implementors is to view
> decorators as an extension to function definition, I believe that the
> separate compound statement view is fairly rich. As others have noted,
> it can make identical decorations simpler:
> 
> @static,synchronized:
>     def foo():
>         pass
>     def bar():
>         pass
I like this idea. What about using the list syntax instead of the @ syntax:

[decorator]:
     def foo():
         pass

[static, synchronized]:
     def foo():
         pass
     def bar():
         pass

[static,
  synchronized,
  types(int, int),
  returns(None)
]:
     def foo():
         pass

This would then take away the argument against a valid list before a def 
being valid python but not previously having any effect...

Or for good measure you could add a keyword:

declare [static, synchronized, types(int, int), returns(None)]:
     def foo():
         pass
     def bar():
         pass

Now that looks pretty neat

David