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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4