[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