Christian Theune <ct@gocept.com> wrote:
Arguably, the check for an attribute would be sufficient if it checked whether an attribute implementation is around -- either by a simple attribute value or a descriptor providing that.
At this point, I guess the outcome of the discussion depends on whether it is considered legal or abuse to implement a data descriptor in such a way that it hides an attribute defined on a base class by raising an AttributeError.
There's another method: verifyClass. This definitely only checks the presence of an implementation.
To be more precise: the declaration of implementation of an interface as opposed to actual implementation of its attributes.
Thomas: There is an issue that we regularly see with verifyClass that makes us instanciated the objects and then use verifyObject. I don't remember what it was right now. Do you?
Not really, other than to avoid the case of a happy verifyClass() call with the application dying of a forgotten attribute implementation. Could there be classes we subclass that claim to implement an interface but don't fully do so until after instantiation? Just a guess... 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