[Python-Dev] method decorators (PEP 318)

Andrew Bennetts andrew-pythondev at puzzling.org
Fri Mar 26 20:42:18 EST 2004


On Fri, Mar 26, 2004 at 01:33:00PM -0600, Skip Montanaro wrote:
> 
>     Robert> However, the idea of putting such attributes at the same level
>     Robert> as the rest of the function block is ugly to me--newbies are
>     Robert> going to go mad the first few times, trying to figure out *when*
>     Robert> such statements are evaluated. 
> 
> An excellent point.  It seems to me that @statements would have to be
> restricted to occur only at the beginning of a function (immediately after
> the def line or the docstring).  If not, you'll probably get people (newbies
> at least) trying to write stuff like this:
> 
>     def foo(a):
>         if a > 5:
>             @attr: "bob"
>         elif a > 0:
>             @attr: "skip"
>         else:
>             @attr: "guido"
> 
> The other forms (via a decorator, using explicit attribute assignments after
> the definition) make it explicit that these attribute assignments don't
> occur in the context of function execution.

I agree -- anything that looks like code, but is run at defintion time
(rather than function call time), should occur before the colon in the def
statement.  To me, that colon is the boundary between declaration and code.

I realise that technically docstrings already break that -- but string
literals are no-ops in code, so it's not a big break.  But attribute
assignments that allow evaluation of arbitrary expressions aren't no-ops, so
I think Skip has a good point here.

I think I'd rather stick with just "def func(args...) [decorators]:" for now
-- it already makes setting function attributes much easier than is possible
now, and will hopefully give us some actual experience in what people want
to do, rather than just speculation.  Adding "@foo: bar" feels like a very
big (and controversial!) addition for very minimal benefit over what PEP 318
already allows.

-Andrew.




More information about the Python-Dev mailing list