[Python-Dev] method decorators (PEP 318) (original) (raw)
Greg Ewing greg at cosc.canterbury.ac.nz
Sun Mar 28 22:07:43 EST 2004
- Previous message: [Python-Dev] method decorators (PEP 318)
- Next message: [Python-Dev] method decorators (PEP 318)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 +--------------------------------------+
- Previous message: [Python-Dev] method decorators (PEP 318)
- Next message: [Python-Dev] method decorators (PEP 318)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]