I would like to propose an extension to behavior the decorator syntax. For @decorator '@' should see if decorator supplies a __decorate__ method. If so, call the __decorate__ method. Otherwise, call decorator directly.<br>
<br>Guido does say that __decorate__ should not replace __call__ here <a href="http://markmail.org/message/ig6diu6j55flxr6c">http://markmail.org/message/ig6diu6j55flxr6c</a>, saying<br><br>"""<br>Q: Is there a strong feeling (in any 
direction) about 
calling the decorator's "decorate" or "__decorate__"
attribute, rather than its "__call__" attribute?
<p>
A: It should be __call__; that's the only backwards compatible way, and
makes it easy to create decorators as functions.<br></p><p>"""<br></p>(Sidenote: Can someone explain what the backward incompatibility is?)<br><br>There is one use case I have run into where I wanted to make a distinction between __call__ and __decorate__. It is a Null object, which is like None but supplies several interfaces. It's an empty collection, a context that does nothing, a callable that returns None, and should be a decorator that returns the original function - except that it's already a callable that returns None. This object is cool for doing stuff like:<br>
"""<br>with (blocking if block else Null):<br>   doSomething()<br>"""<br>Rather than<br>"""<br>if block:<br>   with blocking:<br>      doSomething()<br>else:<br>   doSomething<br>
"""<br>And, it fits in several spots like "os.walk(x, onerror=Null)" for example.<br><br>I'll admit, the use case here is fairly spurious. There may be use cases which are more 'real'. If not, <em>C'est la vie</em>.<br>
<br>--<br clear="all">Zachary Burns<br>(407)590-4814<br>Aim - Zac256FL<br>Production Engineer<br>Zindagi Games<br>