[Zope-dev] zope.interface: verifyObject vs properties

[Dieter Maurer]

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