At 09:31 PM 3/31/04 +0100, Mark Russell wrote:
>On Wed, 2004-03-31 at 20:20, Guido van Rossum wrote:
> > > I suggest that the the break-less solution
> > >
> > > [classmethod, logged, debug] def function(args):
> >
> > Sorry, can't do that with the current parser.
>
>Actually I think that's a good thing - it forces everyone to format
>things the same way. I was a fan of the "def foo() [decorator]" syntax
>but I've changed my mind - this way has several things going for it:
>
> - Simple implementation
> - More or less forces one style of code layout
> - Doesn't break tools that look for "def foo(" type patterns
>` - Short-circuits the endless syntax discussion :-)
Um, perhaps I'm confused, but that sounds to me like a list of reasons to
go with decorators-last. :)
Conversely, the magic list-on-one-line, def-on-the-next is *so* implicit
and error-prone in so many respects that it makes me want to vote against
having decorator syntax at all. Certainly, it's providing me with a strong
motivation to see if I can find a way to make the current parser handle the
"list on the same line" variation without a complete rewrite. Perhaps a
sneaky trick like this:
expr_stmt: testlist (augassign testlist | ('=' testlist)* | [funcdef |
classdef] )
with a special case check that the testlist consists solely of a list, that
triggers a syntax error at the funcdef or classdef point.
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