[Python-Dev] Re: Another approach to decorators.

[Bob Ippolito]

On Aug 12, 2004, at 4:53 PM, Guido van Rossum wrote:

>>> I think this is too far-fetched to consider as an alternative to the
>>> humble @decorator.
>>
>> Maybe, but if you're still serious about improving support for
>> domain-specific embedded languages in Python you ought to give the
>> ideas another look.  If a reasonable syntax for decorators falls out
>> of a more general and useful mechanism, so much the better.
>
> How does
>
>     decorate <expr>, ...:
>        <block>
>
> improve support for domain-specific embedded languages?

I guess it depends on what is passed to the decorators.  If enough 
information is passed to the decorators it might almost be like a 
macro.  Practically speaking, I don't see how it would help very much 
considering that the block would be executed before the expression.  If 
it wasn't executed before the decorators, then I don't see how it would 
be any better than

	@<expr>
	def throwawayname():
		<block>

I suppose that decorators in the decorate <expr>, ...: <block> syntax 
would take a dict of the block's local namespace and return a dict of 
anything that should be set in the local namespace of the decorate 
statement.

But now that I think about it some more, it would probably be more 
useful to domain-specific languages if the decorators were allowed to 
modify the namespace *before* and *after* the block.  For example, to 
import a whole bunch of stuff for a domain specific purpose (say, 
writing SQL code, doing AppleEvents, etc.) and then get rid of it 
afterwards?

Anyway, I think that the decorate <expr>, ...: syntax might be useful 
someday, but I don't think that it could usefully have the same 
semantics as the current decorator PEP.

-bob