[Interface-dev] Twisted usage of zope interface in Zope3 SVN
radix at twistedmatrix.com
Mon Sep 25 20:01:55 EDT 2006
On 9/25/06, Jim Fulton <jim at zope.com> wrote:
> On Sep 22, 2006, at 5:08 PM, Christopher Armstrong wrote:
> > Now, if there is a method IFoo.__adapt__, and one calls IFoo(o),
> > that method will not be called when using the C optimizations,
> > because the C implementation of __call__ just directly calls the C
> > implementation of __adapt__ without looking it up as a method on
> > the interface object.
> > Is this a bug?
> No. PEP 246 doesn't specify a protocol __call__ method so I don't
> feel bound by it. I never considered it a use case to be able to
> override __adapt__ for interfaces. If you want to do that, then
> you'll have to override __call__ as well. Do you want to override
> __adapt__? If so, why?
That's fine, I guess. One could argue that the documentation is at least
unclear or perhaps even incorrect, on this point, then:
This method is normally not called directly. It is called by the PEP
246 adapt framework and by the interface __call__ operator.
Technically, __call__ doesn't call the __adapt__ method on the interface: in
(the new version of) C-optimized mode, it calls some internal C function
called __adapt__ which isn't a method on Interface; and this is noticeable
if you try to override __adapt__, because __call__ won't call it. Anyway,
I'm not that concerned with Zope PEP 246 compatibility.
To answer your question about why we're overriding __adapt__: I didn't do
this myself, but I tracked down the developer who did and he claimed that
this was a more efficient way of overriding the way one particular interface
adapts things. Adding an adapter_hook adds an extra function call and
extends check to a ton of potential interface adaptations. I guess I will
try to convert this to an overridden __call__.
International Man of Twistery
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interface-dev