[Python-Dev] PEP 318
Jewett, Jim J
jim.jewett at eds.com
Tue Mar 23 15:47:48 EST 2004
PEP-318 (Skip):
>> def func [dec1, dec2, ...] (arg1, arg2, ...):
>> pass
>> ... For short lists it works okay, but for long list it separates
>> the argument list from the function name.
Guido van Rossum:
> OTOH, for long argument lists, the "preferred" form has the reverse
> problem: the decorators are separated from the function name by the
> long argument list.
I know it is common to look for "what would I call this with".
I suppose staticmethod and classmethod are important because they
change that calling signature.
Are other decorators expected to be something people would scan for?
If not, then having them at the top of the function (so you see them
if you're reading the whole function) is probably enough.
> ... what is more likely: long argument lists or long lists of
> decorators? I *know* that (at least in certain code bases :)
> long argument lists are common.
I suspect those same code bases will pass long argument lists to
several of the individual decorators. Anders Munch's original
release example used more than two keywords. I believe the following
example is just as reasonable as a long argument list.
Before the def, using an optional second header clause on the
funcdef production:
using:
release(version="1.0",
author="me",
status="Well I wrote it so it works, m'kay?",
warning="You might want to use the Foo class instead")
provides_API_myweb
synchronized(lock[23])
def foo(arg1, arg2):
pass
In the middle:
def foo as [release(version="1.0",
author="me",
status="Well I wrote it so it works, m'kay?",
# Line length becomes an issue
warning="You might want to use the Foo class instead"),
provides_API_myweb,
synchronized(lock[23])] (arg1, arg2):
pass
At the end:
def foo(arg1, arg2) as [release(version="1.0",
author="me",
# Line length becomes an issue
status="Well I wrote it so it works, m'kay?",
warning="You might want to use the Foo class instead"),
provides_API_myweb,
synchronized(lock[23])]:
pass
More information about the Python-Dev
mailing list