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
_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to