[Python-Dev] Re: PEP 318: Decorators last before colon (original) (raw)
Phillip J. Eby pje at telecommunity.com
Wed Mar 31 15:51:28 EST 2004
- Previous message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Next message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Next message: [Python-Dev] Re: PEP 318: Decorators last before colon
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]