Re: A summary of "Interfaces vs ZCA concepts"
Martijn Faassen <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <[email protected]> |
Hey, Ethan Jucovy wrote: > On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen > <[email protected]> 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 _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )