Tres Seaver wrote at 2008-10-17 15:14 -0400:
> ...
>> "verifyObject/verifyClass" is likely not to handle the following
>> case correctly:
>>      class I(Interface):
>>        def m(...):
>>          ...
>>      class C(object):
>>        implements(I)
>>        m = property(lambda self: lambda ...: ...)
>> i.e. when a method (declared by the interface) is implemented by a property.
>Why would I want to do that, rather than using 'def m(self):'?

Why do you want to compute (non-method) attributes rather than
define them directly on the class or set them on the instance?

Indeed, defining methods by means of descriptors is not uncommon.
"staticmethod" and "classmethod" are prominent examples.
Fortunately for "verifyClass", they return "function" and "method" when
resolved on a class. Would they not, "verifyClass" would fail (as in
the "property" case).

I have been wrong with respect to "verifyObject": "verifyObject"
handles the case correctly.

I hit a (minor) error when I made some tests to answer your question:

from zope.interface import Interface, implements
from zope.interface.verify import verifyObject, verifyClass

>>> class I(Interface):
...   def m(): pass
>>> class C(object):
...   implements(I)
...   @classmethod
...   def m(): pass
>>> c=C()
>>> verifyObject(I, c)
>>> verifyClass(I, C)
>>> c.m()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: m() takes no arguments (1 given)

I.e. the Zope3 "verify" does not catch that a classmethod
needs an argument where the class can be passed in.

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to