At 04:47 AM 3/31/2006 -0800, Michael Chermside wrote:
In the discussion over class decorators, Jim Jewett writes:
I have often started with a function, and ended up replacing it with a callable object so that I could save state without resorting to "defalt args" or worse.
I would prefer to decorate these exactly like the functions they replace.
I have observed the entire discussion about class decorators with absolutely no opinion, until I read Jim's brief post quoted above. I am now completely convinced that class decorators ought to exist and behave exactly like function decorators. Thanks, Jim for pointing out what should have been obvious to me from the start. The ability to use callable objects as functions is a powerful tool in Python, and ought not be broken by decorator inconsistencies.
Unless the class has a metaclass implementing __call__, or you mean that you want instance creation to be a call, I don't understand what you mean. Nonetheless, the discussion has only been about *where* the decorators go and what syntax they use. Nobody has proposed any change in decorator semantics, so please stop attacking this meaningless strawman. Moving from: @foo def bar(...): ... to: class bar: @class foo def __init___(...): ... instead of: @foo class bar: def __init___(...): ... is a trivial difference in editing: you type "class " one more time.
On Friday 31 March 2006 11:52, Phillip J. Eby wrote:
class bar: @class foo def __init___(...): ...
The more I think about it, the more I like the "@class foo" syntax. The existing syntax for functions doesn't have anything between the decorators and the "def"; having class decorators embedded within the class should still allow the docstring to be the first thing, so there's more distance between the decorator and the name being decorated. The extra hint about what's being decorated is nice. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
participants (2)
-
Fred L. Drake, Jr.
-
Phillip J. Eby