[Python-Dev] Re: new syntax for wrapping (PEP 318)

[Jeremy Fincher]

On Thursday 26 February 2004 01:58 am, Shalabh Chaturvedi wrote:
> > Putting the decorator between the def and the method name actually
> > doesn't look so bad to me, e.g.:
> >
> > def [classmethod] func(a, b, c):
> >
> > but I think with a longer decorator list, it might be problematic.  I
> > think that one element decorator lists will be the most common use and
> > in that case, I like this syntax because it almost reads like English.
>
> 
> I completely agree. This is the second-most elegant syntax, the
> most-elegant being:
> 
> def classmethod func(a, b, c):

I also much prefer this syntax to any other suggested syntax.  Perhaps it's 
because I'm used to C (or practically any other language with type 
declarations), which puts type declarations ("restraints") before the defined 
function rather than after.

> Has this been completely rejected? The pep's argument is it becomes
> cluttered and obscure when the decorator is a function call:
> 
> def synchronized(lock) classmethod func(a):
> 
> Can we also require that decorators be identifiers only (no expressions
> allowed), forcing clean looking definitions?

This would be fine with me.  I would sacrifice the slight inconvenience of 
having to write give something a name in order to have what I believe to be 
significantly more readable code (much like I do with lambdas: I sacrifice 
the convenience of having an unnamed function on one line of code in order to 
maintain readability).

> sync = synchronized(lock)
> def sync classmethod func(a):

This is much more readable, IMO, than:

def func(a) [synchronized(lock), classmethod]:

Jeremy