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).
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -