[Python-Dev] Re: PEP 318: Decorators last before colon

[Guido van Rossum]

> There are different kinds of aesthetics.  Guido's proposal has grown
> on me from a *visual* aesthetics point of view.  After I worked with
> it a little bit, I realized it really is much prettier than
> decorators-before-colon.

Right.  It really is.

> However, from more intellectual aesthetics (consistency,
> predictability, etc.) I still dislike it, and don't really see how
> to sanely reconcile it with the Python syntax of today.  I wish that
> I did, because it really does *look* better for simple decorators.

I, too, wish that there were a way to make it work with current
expectations.  The * prefix looks so arbitrary: why not /, why not @,
etc...

> On the other hand, *no* syntax proposed so far has been really that
> nice to look at when used for multiple decorators.

Yet, decorator-before-def does better there, too, because it gives you
more horizontal space to work with.  This is useful for decorators
that take argument lists, like the ObjC decorator and I believe some
of PEAK's decorators.  (I don't want to use funcattrs() as an argument
here, because I believe that it is simply an inevitable by-product of
introducing any kind of decorator syntax -- while far from perfect, in
terms of readability setting function attributes in a decorator is so
much better than setting them after the function has been defined,
that I believe we have no choice but to provide it.  (Similar for
synchronized, except I feel less pressure to add it; I'd much rather
introduce some kind of general block wrapper feature like we have
discussed many times here.))

I also note that accepting decorator-before-colon now would make it
harder to come up with a decent syntax for declaring the return type,
which I still want to do in some future version of Python with
optional (!) static typing.  But not impossible -- there's enough
punctuation available besides '[' and ':'.

I also note that the proposed variants that prefix the 'def clause'
with another (optional) indented clause, started e.g. by 'with:' or
'decorate:', look much worse.  They violate another strong expectation
in Python: that a suite is a sequence of statements.  (And it really
can't be a sequence of statements -- e.g. assignments just really
don't make sense as decorators, nor do many other forms of statement.)

One worry about every syntax that supports multiple decorators: as
soon as there's a transformation among the decorators, they stop being
commutative.  And that could cause a load of problems with beginners
trying their hand at using complicated decorators (e.g. trying to
define a class property by combining classmethod and property).

--Guido van Rossum (home page: http://www.python.org/~guido/)