Maybe, just maybe @decorator syntax is ok after all

[AdSR]

Ville Vainio <ville at spammers.com> wrote in message news:<du7n017ni6o.fsf at mozart.cc.tut.fi>...
> It might just be that @decorator might not be all that bad. When you
> look at code that uses it it's not that ugly after all.

You know what, I'm starting to feel the same. Yesterday Anthony Baxter
mentioned this URL:

http://mail.python.org/pipermail/python-dev/2004-August/047112.html

where GvR says:

"""
Given that the whole point of adding decorator syntax is to move the
decorator from the end ("foo = staticmethod(foo)" after a 100-line
body) to the front, where it is more in-your-face, it should IMO be
moved all the way to the front.
"""

And I had the sudden feeling that I finally got it. You see, for me,
the @decorator syntax is a declaration - first thing that came to my
mind was Pascal's "forward". So it says "take the def that follows and
insert a (old style) decoration line in the code after it." Note that
here the "def" is recursive - it may have other @decorators before it.

I'm not sure I'm making myself clear; my understanding of it is more
by feeling than by logic. So let's say that @decorator is like a
preprocessor directive. If we have:

@dec1
@dec2
def foo():
    pass

then after the first pass it becomes:

@dec2
def foo():
    pass

foo = dec1(foo)

and after the second:

def foo():
    pass

foo = dec2(foo)

foo = dec1(foo)

BTW, this interpretation leaves some space for future manipulation of
if/for/while/try statements.

Speaking of loop statements, they have an optional else clause that
isn't obvious either. It means "do this if there was no break-exit
from the loop." Yet for me the obvious meaning would be "if there were
no loop passes" - that is, the while condition was false on the first
entry or the for list was empty. I think the word "finally" would be
more to the point here (and it's a keyword anyway).

I think having some obscurity in the language is inevitable. The
present way of applying decorators (x = decor(x)) is equally cryptic
to a newbie as the @decor syntax will be - first you have to know what
a decorator is. There even aren't any decorators used in the standard
lib - or at least grep doesn't show any static/classmethod rebindings.

> My chief worry was throwing away one of the few unused ascii symbols,
> but if we take a look at perl6, there is a lot of promising unicode
> symbols to choose from in the future ;-). Also, there is still @(),
> @#, @{} and others in the hypothetical event BDFL would like to use @
> for future features like macros, ruby blocks or whatever.

And we still have ? and $, plus the backtick (`) that now is for repr,
but in Python 3000 will hopefully be for "os.popen.read(); ...close()"
like in bash for example, or something equally useful.

> So I would vote +0 for @decorator if we were in the parallel universe
> where that mattered. Two days ago I was -10.

Same here. I'm opposed to dictatorship in general - I grew up behind
the Iron Curtain - but the BDFL's decisions so far were mostly
beneficial, so I'll live with whatever he decides (I'm not saying this
as seriously as it sounds).

AdSR