[Python-Dev] Re: Decorators: vertical bar syntax

Fernando Perez fperez528 at yahoo.com
Mon Aug 9 19:50:19 CEST 2004


Guido van Rossum wrote:

> [Guido]
>> > In the discussion on decorators months ago, solutions involving
>> > special syntax inside the block were ruled out early on.  Basically,
>> > you shouldn't have to peek inside the block to find out important
>> > external properties of the function.
> 
> [Bill Janssen]
>> Guido, could you expand on this principle a bit?  Just stated as it

> It's probably untenable as a formal principle. :-)
> 
> Nevertheless I don't like to put decorators in the method body.  I
> think it has something to do with the fact that normally one thinks of
> the body contents as relevalt to "call-time" while decorators happen
> at "definition-time".

I realize what your current position on this topic is, but I'd like to
encourage you to at least reconsider it for a moment.  In python we've come to
consider, for better or worse, the section up to the end of the docstring, as
a kind of 'header' or 'interface' zone for functions.  I know you dislike the
docstrings as an example of this, but in fact I don't view it as such a bad
thing: the def indents and clearly separates the function, and for a while you
have 'interface' information: function name, argument list, docstring, and
perhaps now decorators.  This actually feels very clean to me, and seems to
nicely fit the mental model of how python works.

Elsewhere in this thread:
http://mail.python.org/pipermail/python-dev/2004-August/047326.html
and below, I tried to make a reasoned argument in defense of this.  I won't
repeat all that here.

I further worry what will happen to tools like inspect.getsource() with
decorators outside the def:

@foo
@bar
def baz(x,y):
   ....

if I try to get the source for baz, will I see foo/bar?  For introspection
tools, this can lead to pretty misleading results.  But perhaps this is easy
to solve or has even already been taken care of.  I imagine if @foo/@bar were
inside the def, this wouldn't be an issue.

Best,

f



More information about the Python-Dev mailing list