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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )