[Zope-dev] zope.interface: verifyObject vs properties
Dieter Maurer
dieter at handshake.de
Wed Oct 15 14:21:48 EDT 2008
Thomas Lotze wrote at 2008-10-15 09:27 +0200:
>There has been a problem with zope.interface's verifyObject function
>that occurs in conjunction with Python properties: when verifyObject
>checks for the presence of an object's attribute, it does so by using
>hasattr() which in turn tries a getattr() call. If the attribute is
>implemented as a property, this may raise an exception which will be
>masked by hasattr() due to a bare except: clause. One scenario where
>this is a problem is a property that performs some component lookup
>which will succeed at application runtime but not in unit tests where
>verifyObject is commonly used.
>
>While it has also been argued that behaviour so complex that it may
>raise an Exception should not be implemented as a property in the
>first place, we believe that verifyObject should handle this case better
>than it currently does. A possible fix would be to add an additional
>check for a data descriptor on the object's class if the hasattr() test
>returns False.
>
>Are there any objections against modifying verifyObject in this way?
I fear your must describe your proposed change more precisely:
When your problem is the stated use case: "verifyObject" fails
because something necessary for the interface to be properly implemented
is missing in the test but available in a real environment,
I would say: that is very fine: Do not change "verifyObject" but
give the test instead the resources expected to be available in the
real environment.
When you want to provide a better (more informative) exception
(not "fails to implement" but "ComponentLookupError"), then I am with you.
--
Dieter
More information about the Zope-Dev
mailing list