[Python-Dev] Decorators: vertical bar syntax

Bob Ippolito bob at redivi.com
Mon Aug 9 19:02:27 CEST 2004


On Aug 9, 2004, at 12:42 PM, Bill Janssen wrote:

> GvR writes:
>> 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".
>>
>> And before you bring up docstrings as a counterexample, yes, they
>> should ideally have been designed to precede the method, too.
>
> Perhaps another way to think about this is that there are statements
> about properties of the function, method, or class which should
> precede the implementation of the whatever-it-is?  That makes sense to
> me.
>
> But I'm less sure about the relative placement of the name of the
> whatever versus statements about the properties of the whatever.  For
> example, should the argument list also occur before the name of the
> function?  In a perfect world, would Python have the syntax:
>
>   def (param1, param2) funcname:
>      ...
>
> or perhaps:
>
>   @args(param1, param2)
>   def funcname:
>      ...
>
> In thinking about this, I find the argument made a day or two ago
> about "cognitive binding" very powerful.  That is, you should state
> the name of the thing you are defining before you start stating
> properties of it, so that the reader has the opportunity to mentally
> construct a tagged "bucket" to put those properties in.  This is
> probably a useful thing for non-human tools, as well.
>
> Perhaps that's one reason that arguments to a function almost
> universally occur after the mention of the function name, in most
> programming languages:
>
>   def foo (arg1, arg2, ...)
>
> So, by this principle, docstrings occur in the "right place", after
> the function name but before the implementation.  Perhaps this is why
> docstrings are so successful in Python.  Extending the principle to
> decorators would mean that they should occur somewhere between the
> function name and the function implementation.  All of the C, D, and E
> variants in the Wiki seem to support this.  Perhaps one of them is the
> right choice?

Actually I would say that in a perfect world, functions would be 
expressions.  Something like this:

foo = staticmethod(def(*args, **kwargs)):
	....

-bob


More information about the Python-Dev mailing list