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