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
Use a different method to verify your notion of adherence with an interface.
Do not change "verifyObject" for this.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -