On Thu, Sep 24, 2009 at 5:38 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I was thinking about something like this myself recently. I have some custom property classes that I use extensively in a couple of projects, declared like this:
foo = fancy_property('foo', 'The fancy foo property')
It would be nice to be able to write this as something like
@fancy_property foo = 'The fancy foo property'
How did one occurrence of 'foo' suddenly turn into foo (without quotes)? That's not how decorators behave elsewhere.
or perhaps
@fancy_property('The fancy foo property') foo = default_foo_value
I think the interpretation for decorators on things other than classes and functions should be derived by carefully reinterpreting what a decorator does for a function or class. We already have the rule that @fancy def foo......... # or class foo.......... is equivalent to def foo.......... # or class foo.......... foo = fancy(foo) Now in addition we know that def foo........ # or class foo........... means foo = <create something> so we have @fancy def foo........ # or class foo......... as a shorthand for foo = fancy(<create something>)
From this we can conclude that
@fancy foo = <expression> just means foo = fancy(<expression>) which is (IMO) an utterly unattractive violation of TOOWTDI. If you were going to object "but def foo and class foo also pass the string 'foo' into <create something>", my counter-objection is that those semantics are implied by the def/class keywords and not by the @decorator syntax. Ergo, -1. -- --Guido van Rossum (home page: http://www.python.org/~guido/)