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
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