As soon as one of these syntax discussions go on long enough, I start to
think that, whatever the problem ,it should be solved by thunks (search
python dev if you need to know what a thunk is) or something thunk-like.
It's a personal weakness, I suppose. In that vein, here's my entry into
the Great Decorator Debate 2004.
def NAME as EXPRESSION:
BLOCK
BLOCK is executed in a separate namespace *before* EXPRESSION is
evaluated. EXPRESSION is then evaluated in BLOCK's namespace. This is
probably best illustrated with an example or three:
class C:
# The standard staticmethod example. It works reasonably well
for this, but is
# a bit wordier than some examples. It's clear what's happening
though.
def foo as staticmethod(body):
def body(x, y):
#...
# This method generalized nicely to properties, which I like.
def bar as property(getbar, setbar, None, doc):
doc = "That crazy bar property!"
def getbar(self):
#....
def setbar(self, value):
#....
# It's pretty good for the nasty long decorators and arg list case.
def bar as OBJCDecorator("@#%$@#^",
SomeOtherDecorator("asdfasf", body)):
def body(a_long_argument_list, with_long_arg_name, _etc.):
#....
This syntax is by no means perfect; it's a little wordy in the simple
case for one thing. But it's more obvious what's happening in this
syntax than in any of the others that I've seen which I think is a big
plus.
It also generalizes well to the hypothetical Python 3000 with optional
type checking, since the signature can be placed on the user visible
'foo' instead of on the pre-transform body:
def foo(int, int)->int as staticmethod(body):
def body(x, y):
#...
Enjoy,
-tim
