Thomas Lotze wrote at 2008-10-15 20:55 +0200: >"Dieter Maurer" <[EMAIL PROTECTED]> 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.
I do not follow your argumentation: An attribute it not there because there is a descriptor, it is only there when the descriptor provides a value: I have seen descriptors in Zope3 that are only there to remove an attribute that might otherwise be inherited -- by unconditionally raising "AttributeError". In this case, the existance of the particular descriptor precisely means that the attribute is missing. Moreover, when an attribut is implemented by a descriptor, I am very much interested that its "__get__" does not raise an exception. If this is not the case, I would like to be warned early; if possible even by a unit test. This means that I am against your proposed change. >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, Computed attributes introduce a new quality: while a standard attribute is either present or absent, a computed attribute may also raise an exception (and behave exactly like an absent attribute) on access. You want to treat those attributes as present, I do not. >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. I, too, am a user (and was not involved in the design of "verifyObject"). Nevertheless, I do not share your point of view. > .... >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. Use a different method to verify your notion of adherence with an interface. Do not change "verifyObject" for this. -- 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 )