[Zope-dev] Interfaces vs ZCA concepts

[Tres Seaver]

-----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          tseaver at palladion.com
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-----