[PEAK] Re: dispatch.add_assignment_advisor

[Phillip J. Eby]

At 09:58 PM 12/3/04 +0100, Thomas Heller wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
> > I would have expected that too, but I haven't really tested assignment
> > advisors with classes, because we already had class advisors for that.
>
>It works as expected when all the method decorators are removed.

Hm.  I think I know how it's broken, then.  Actually, I remember now that I 
figured out a while back that it's broken because I had a misunderstanding 
about how sys.settrace() worked.  But I didn't think it was actually broken 
in a way that would break anything, if you know what I mean.  :)

Specifically, sys.settrace() is kind of odd.  It sets a global trace 
function that receives all "call" events, but not any other kind of 
events.  A frame's "f_trace" attribute has to be set in order to receive 
"line", "exception" or "return" events for that frame.

add_assignment_advisor is actually written as though there's really only 
one hook, and I meant to fix that so that it would interoperate better with 
debuggers and such, but I haven't gotten around to it.

Anyway, at least now I can add your case to my tests.


> >>Any idea how to make this work as expected?
> >
> > Use 'protocols.advice.addClassAdvisor' instead, and move the
> > 'cominterface' call inside the class body.  Note, however, that
> > addClassAdvisor has a different callback signature; the callback
> > accepts one argument (the incoming class) and must return the desired
> > output class.
>
>Cool.  I cannot pretend to understad addClassAdvisor code, but it seems
>you create a __metaclass__ and let it do the magic.

Yep.  zope.interface uses the same technique (and the same code!) to do 
'implements()' and such.