I suggest that the the break-less solution

[classmethod, logged, debug] def function(args):

Sorry, can't do that with the current parser. --Guido van Rossum (home page: http://www.python.org/~guido/)

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.

Guido van Rossum wrote:

...

A simple issue I have with: [classmethod, logged, debug] def function(args): ... Is "How do you type this into Idle?" I realize this is not the most important of considerations, but access to experimentation is going to be vital. You can always force with:

...

...

...

if True: [classmethod, logged, debug] def function(args): ...

but I wonder if we want to go that route.

Since it will normally be part of a class, you shouldn't have any problem. I expect that toplevel functions with decorators will be rare enough to put up with the "if True" work-around.

This looks ugly to me. I do have top level functions that would use decorators because those functions will be put into a class as classmethods and this class will be put into sys.modules instead of the original module. Replacing def foo(cls): ... foo = classmethod(foo) with if True: [classmethod] def foo(cls): ... doesn't look that attractive to me. Bye, Walter Dörwald

Guido van Rossum wrote:

...

This looks ugly to me. I do have top level functions that would use decorators because those functions will be put into a class as classmethods and this class will be put into sys.modules instead of the original module. Replacing

def foo(cls): ... foo = classmethod(foo)

with

if True: [classmethod] def foo(cls): ...

doesn't look that attractive to me.

You won't have to do that except in interactive mode. How often do you type functions that need decorators interactively?

Wouldn't a small addition to your syntax make all these (special case) problems disappear and, perhaps, go some way to making the syntax more readable (particularly for beginners):: as: [classmethod] def func(args) I'm a relative newbie to Python (12 months but many, many years elsewhere) which means I'm only qualified to comment on what a newbie would find confusing and I can assure you an isolated list on a line by itself or having to read about "if True:" work-arounds, would be remarkably confusing in a language where so much else happens just the way you would expect. If the decorator list is to go first and on the line above, then the 'as:' syntax just looks so right to my newbie eyes and sensibilities. It even read fairly well for the oft given 'classmethod' and 'staticmethod' use cases. -- Mike

At 10:19 PM 3/31/04 -0500, Terry Reedy wrote:

"Mike Thompson" wrote in message news:c4fk3i$ujb$1@sea.gmane.org...

...

as: [classmethod] def func(args)

I think I like this better than the bare list as a prefix. as: suites could be explained as an optional prefix suite for functions just as else: suites are optional suffix suites for if/while/for. Hmmm...

'as' is not currently a keyword, and making it so would break any programs that use it as a name. On the bright side, if it *were* made a keyword, then this would be possible: as [classmethod] def func(*args): pass Really, of the current "before the def" proposals, I think I like Samuele's: *[classmethod] def func(*args): pass approach the best. The '*' seems to say "special note, pay attention". :)