[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