[Python-Dev] A usability argument for list-after-def

[Phillip J. Eby]

At 11:52 PM 8/5/04 +0200, Gregory Lielens wrote:

> > Of the options on the Wiki page ( at
> > http://www.python.org/moin/PythonDecorators ), this seems to
> > leave only
> > list-after-def, the previous community favorite and the first PEP 318
> > syntax to have been implemented.
> >
> > Guido's principal argument against list-after-def, if I
> > recall correctly,
> > was that it is ugly when multiple or lengthy decorators are
> > involved.  But,
> > "ugly" isn't an argument any more, so that shouldn't rule out
> > list-after-def.  :)
>
>On a cosmetic point of view, I also prefer the list-after-def syntax,
>first time I saw it it was the one than seemed the easiest (the "def f()
>as [decorator]" variant was event clearer, but the argument that as is
>only for renaming has mitigaed that somewhat ;-) )
>"Cosmetic" does not sound like a very convincing argument, but I feel
>that this whole discussion is purely on a cosmetic level anyway, it is
>just a way to express more clearly something that is already
>possible...and as feedback as been asked for... ;-)
>
>But does it means that the list-after-def behaves like all lists, so
>that these are possible and equivalent?
>
>def foo() [decorator1, decorator2(bar)]:
>    ...
>
>def foo() [
>     decorator1,
>     decorator2(bar)]:
>    ...
>
>my_complex_decorator=[decorator1, decorator2(bar)]
>def foo() my_complex_decorator :
>    ...

The third example isn't allowed, but the first two are.  Remember that part 
of the point is that the [] are being used to visually signal 
annotation.  The third syntax loses this point.

Note that there is precedent for this kind of syntax restriction; a class' 
bases are a tuple, but that doesn't mean you can do this:

     yz = (Y,Z)

     class X yz:
         pass