Guido:
> If we were going to use this mostly for decorators spelled with a
> single work, like classmethod, I would favor a syntax where the
> decorator(s) are put as early as reasonable in the function definition
Not only single-word decorators, but an extremely small number of them
applied to a given function.
> After seeing all the examples, I still worry that this:
>
> def foobar(cls, blooh, blah) [classmethod]:
>
> hides a more important fact for understanding it (classmethod) behind
> some less important facts (the argument list).
Classmethod and staticmethod seem to be somewhat special in this
regard. In most of the other use cases put forward, the decorators
aren't so important for knowing how to use the function. In other
words, they're more a part of the function's implementation than its
interface.
Maybe there's a case for providing an even more special syntax for
classmethod and staticmethod, and not trying to shoehorn them into a
general decorator syntax?
If we were designing Python 3.0 here, I would probably suggest the
following syntax for classmethods:
def foo(class cls, x, y):
...
and wouldn't bother with staticmethods at all. How often do you
actually need a staticmethod in particular and *not* a classmethod?
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg at cosc.canterbury.ac.nz +--------------------------------------+
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