PEP-318, billion-and-first syntax proposal

[Tim Hochberg]

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