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 )