Maybe, just maybe @decorator syntax is ok after all

AdSR artur_spruce at yahoo.com
Sun Aug 8 14:22:02 CEST 2004


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



More information about the Python-list mailing list