[Python-Dev] Re: Another approach to decorators.
Bob Ippolito
bob at redivi.com
Thu Aug 12 23:25:24 CEST 2004
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
More information about the Python-Dev
mailing list