Re: Interfaces vs ZCA concepts
Tres Seaver <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote: > 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. If so, that code is already broken: it depends on an undocumented implementation detail (of a non-API method). The patch makes the __call__ method an API, and documents the (new) exception type. Anybody whose code breaks when this happens can hold off upgrading zope.interface until they fix that usage. > 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. __call__ is not an API, so again, anybody relying on its argument names can hold off on upgrading. > I think this needs some more thinking, unfortunately. I wish I could see > a gradual way forward on moving from TypeError to LookupError. I don't see any way, or any benefit, to holding off. Just publish the new version (with a bump), and let people find and fix the problematic places in their code as they upgrade. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksrvcMACgkQ+gerLs4ltQ5bewCg1jxWXSGE/cj+1OJ8X9yc0IIN KUcAnilGOd2LdOA4ZXtUKYSMVfbMLYGl =BkFw -----END PGP SIGNATURE----- _______________________________________________ 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 )