[Zope-dev] A summary of "Interfaces vs ZCA concepts"

[Martijn Faassen]

Hey,

Ethan Jucovy wrote:
> On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen 
> <faassen at startifact.com> wrote:
>> * It'd be nice if __call__ came back with a LookupError instead of
>> a TypeError, but how to get from A to B without breakage?
> 
> Maybe I've misunderstanding, but what's the advantage of making 
> IFoo(x) raise a LookupError instead of a TypeError?  I've tried to 
> follow the thread but I've been confused about this.  I do rely on 
> catching TypeErrors quite often in my code -- I had thought it was 
> intended as part of the API.

Consistency. The other lookup APIs in zope.component raise
ComponentLookupError, which is a kind of LookupError.

Good data point about catching TypeError though - I don't think we can
just make a release that breaks this.

> I like that treating it as typecasting instead of lookup blurs the 
> conceptual distinction between "adapting x to IFoo" and "asserting x 
> implements IFoo directly" -- when I actually want to know one or the 
> other I can use explicit adaptation or check providedBy.  In other 
> words I use IFoo(x) when I don't care whether IFoo(x) == x.

Yeah, TypeError makes sense from the type casting perspective.

Perhaps my earlier idea about a new Error that subclasses both TypeError 
and LookupError isn't so ugly after all.. After all a failure to look up 
an adapter can easily be interpreted as both.

Regards,

Martijn