[Python-Dev] A usability argument for list-after-def
Phillip J. Eby
pje at telecommunity.com
Fri Aug 6 00:15:09 CEST 2004
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
More information about the Python-Dev
mailing list