@decorators

[daishi]

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