[Python-Dev] Decorators: vertical bar syntax (original) (raw)

Bill Janssen janssen at parc.com
Mon Aug 9 18:42:24 CEST 2004

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?

Bill

More information about the Python-Dev mailing list