-
Notifications
You must be signed in to change notification settings - Fork 845
Description
Since the update to version 301, we have noticed the following change in behavior:
We are working on a class Application whose code was generated with makepy:
...
from win32com.client import CoClassBaseClass
class Application(CoClassBaseClass): # A CoClass
CLSID = IID('{9A872070-0A06-11D1-90B7-00A024CE2744}')
coclass_sources = [
]
coclass_interfaces = [
_Application,
_IApplication,
]
default_interface = _Application
...The following code now causes an AttributeError:
...
app = Application()
bool(app) # -> AttributeError: <x.x.x._Application instance at ...> object has no attribute '__len__'
...Here is my analysis:
Calling bool with app as parameter causes the Python interpreter to try to call the __bool__ method on the object if the method exists. If it does not, then it will try to call the __len__ method. If this does not exist either, then True is returned (Source: python.org).
This means that neither of these two methods must be implemented in a mandatory way for the bool method to work.
If I see it right, the Application class (respectively the CoClassBaseClass class) is just a wrapper around a other class, in my case the _Application class, which is held in self.__dict__["_dispobj_"].
The _Application class in my case has neither the __bool__ nor the __len__ method implemented (which is legal).
Since version 301 some methods (including __len__) are now implemented on the CoClassBaseClass class and the calls are delegated to the _Application class (Commit).
I'm not sure, but I could imagine that this is the problem. The Python interpreter finds the implementation of the __len__ method and then calls it, even if it doesn't really exist on _Application, which leads to the AttributeError.
My expectation would be that calling bool with an Application object as parameter would return True.