August 09, 2004
Python Decorators

Python-land seems to have descended into chaos while I've been away. I suppose I'd better leave someone in charge next time I go on holiday. ;-)

The source of the problem is function decoration, which offers a way to mutate a function or method. The cardinal example of a function decorator might be staticmethod(), Python's way of building static methods. Currently, you have to declare and code the function, then call staticmethod() passing your function as an argument:

class MyClass:
    def my_method(arg1, arg2, ...):
    my_method = staticmethod(my_method)

This is bad for two reasons; firstly, the code which defines my_method as static is not in the same place as the definition of the function itself - it may be a long way away in the case of long methods, and secondly there's the non-critical but irritating fact that you need to enter the method's name three times, violating the DRY principal.

Enter function decorators. The current implementation spells decoration like this:

class MyClass:
    def my_method(arg1, arg2, ...):

Now, I dislike this for two reasons. Firstly, it's ugly. This matters. Secondly, it's not in the function - it doesn't really look like part of it. I'm not alone in disliking this syntax.

I prefer Phillip J. Eby's list-after-def proposal:

class MyClass:
    def my_method(arg1, arg2, ...) [staticmethod]:

Much nicer, at least in simple cases. Things get more complicated where you have multiple decorators, and/or the decorators take arguments themselves, but I don't believe that these will come up too often - especially not the second.

Anyway, that's enough from me; this discussion has generated over six hundred emails to python-dev over the last week, and I don't have anything new to add. I'm sure that whatever Guido ends up deciding on, it'll be OK in the end. He knows what he's doing.

I've not even started reading last week's ;-)

Posted to Python by Simon Brunning at August 09, 2004 01:43 PM
Post a comment

Email Address:



Remember info?