"Dieter Maurer" <dieter@handshake.de> wrote:
I fear your must describe your proposed change more precisely:
Nothing to be afraid of here ;o)
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,
Yes, this is what I'm talking about.
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.
I think this line of reasoning intermingles two different things to be tested: the existence of an implementation of an attribute (as a data descriptor, whatever its getter method tries to do), and whether the attribute's value is sensible at any given point of time. You can compare this to a plain attribute promised by an interface: if it exists on an object that claims to provide the interface, verifyObject will be happy. The attribute's particular value at the time verifyObject looks at it may still be something very stupid from the point of view of the application. The latter is the subject of a different test, not one of interface implementation. To put it differently: If I implement a class and give its instances all attributes defined by a given interface then I expect verifyObject to damn well see that those attributes are there, without having to do all sorts of stuff in a completely different part of the code just in order to satisfy verifyObject's implementation. I'm aware that this is purely from the point of view of the user and does not take into account any design discussions that may have taken place when verifyObject was created.
When you want to provide a better (more informative) exception (not "fails to implement" but "ComponentLookupError"), then I am with you.
This would be better than the current behaviour, but it would still lie because of the difference between the existence of an implementation of the attribute in question and its successful execution in a given set of circumstances. Thomas -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development