On Tuesday 28 March 2006 22:06, Phillip J. Eby wrote: > And here it is: because the use cases for class decorators are > different.
This is vague. > I routinely use them with things that take numerous keyword > arguments, but this isn't nearly as common of a scenario for function > decorators. The zope.formlib decorators are commonly used with many arguments; those construct the replacements and register with a class-specific registry. > Also, class decorators are far more likely to be just > registering the class with something -- which means they don't deserve so > prominent a location as to obscure the class itself. I've not looked at the Java and C# examples, so I don't claim anything about those examples. For all the cases where I'm registering classes, however, it's not a local registry, but something that lives elsewhere in the system; it doesn't affect the class itself at all. I'm happy for that use case to be supported in other ways than prefixing the class with decorator-syntax stuff. > ObDisclaimer: this is my personal experience and opinion. Others may have > different use cases in mind. I'm just pointing out that if @decorator > support were added for classes, I wouldn't use it, because it's not > actually an improvement over what I'm doing now. So it doesn't apply. I suspect this is something for which familiarity with the use cases for the Java and C# precedents would help. For Zope 3, we have decorators that work with the component architecture (I'm sure Phillip is familiar with these). They're used with functions to indicate that the function adapts a particular kind of object, or that it implements or provides a particular interface. We have different functions that get used for this purpose in classes that are executed within the body of the class. There's some merit to being able to use a single set of functions in both cases, since the use cases are the same. I'm not sure I'd want to change the existing pattern, though, since it's already so widespread within the Zope 3 codebase (including 3rd-party components). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
