[Zope-dev] Interfaces vs ZCA concepts

[Martijn Faassen]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martin Aspeli wrote:
>> Tres Seaver wrote:
>>
>>> In either case, I think TypeError (or maybe LookupError) is the *right*
>>> choice:  we don't want to "hide" zope.component's API functions and then
>>> turn around and require folks to import zope.component just to catch its
>>> local exception types.
>> Yeah, that's a compelling reason.
> 
> I have checked in a branch which makes failed adaptation (inside the
> __call__ of an interface) raise a LookupError instead of a TypeError:
> the branch also documents the semantics of __call__.  I would like to
> merge this to the trunk a 3.6.0 version (bumped to indicate the
> quasi-API change).
> 
> http://svn.zope.org/zope.interface/branches/tseaver-raise_lookup_error/?rev=106688&view=rev

While I'm fine with the principle of this change, I do consider it 
dangerous - people might be catching TypeError now instead of using the 
"alternate" argument. Quite a bit of code depending on TypeError (even 
if undocumented) might unexpectedly break.

We could support both errors by introducing an exception that subclasses 
both TypeError and LookupError. The question is whether such a strategy 
would help us deprecate TypeError altogether - I don't see how we can 
detect that TypeError was caught instead of LookupError when our 
exception is handled, so we can't output any messages..

Besides this you've documented the default argument as "default" while 
it is in fact "alternate" (which we want to deprecate in favor of 
default), so the documentation of __call__ isn't correct.

I think this needs some more thinking, unfortunately. I wish I could see 
a gradual way forward on moving from TypeError to LookupError.

Regards,

Martijn