[PEAK] Decorators for PyProtocols and PEAK?
Phillip J. Eby
pje at telecommunity.com
Fri Jun 25 02:01:06 EDT 2004
Check this out:
http://mail.python.org/pipermail/python-dev/2004-June/045583.html
David Abrahams suggested a possible implementation strategy for doing
decorators that didn't involve any syntax changes to the language, and I
whipped up a proof-of-concept that works even in Python 2.2. Basically, it
lets you do this:
[some_decoration()]
def some_function(...):
...
Where 'some_decoration' performs some sort of magical transformation on
'some_function'. I'm pretty pumped about it, because PEP 318 has
languished for a year now, and it was looking like it might not make it
into Python 2.4. If only I'd thought of David's approach a year
ago! Anyway, for peak.events we might use it thus:
[events.taskFactory()]
def some_task(self):
# do event-driven stuff
And for PyProtocols, we might do things like:
[protocols.advise(functionProvides=[ISomeSignature])]
def some_function(...):
...
and maybe even:
[protocols.generic(forTypes=[SomeNodeClass])]
def visit(node, ...):
# Implementation of 'visit' for 'SomeNodeClass'
[protocols.generic(forTypes=[OtherNodeType])]
def visit(node, ...):
# Implementation of 'visit' for 'OtherNodeType'
as a way of doing "generic functions". Slick, eh? (When you call 'visit',
the correct implementation is automatically selected; other modules can
extend the function by importing it and defining more generics with the
same name.)
Couple of interesting questions though... What order should this sort of
advice be applied in? That is, given:
[x(), y(), z()]
def abc(...):
...
Should x() get first crack at the function, or z()? Thoughts, anyone?
More information about the PEAK
mailing list