Thomas Lotze wrote at 2008-10-15 20:55 +0200:
"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.
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