CoClassBaseClass incorrectly sets special methods

[panda-34]

There's an issue with xlwings which was introduced with pywin32 v302:
xlwings/xlwings#1789 (comment)
current implementation of win32com.client.CoClassBaseClass

pywin32/com/win32com/client/__init__.py

Line 628 in 1e7016c

for maybe in [

injects special methods on the instance via setattr(self, '__specialmethod__')
please note, that such methods can only be called explicitly i.e. instance.__call__() but not implicitly instance() , in which case special method is always called from the class, and if the class doesn't define the method then you'll get an error (object is not callable in this case). I didn't investigate xlwings but I suppose that such implicit call produces an error which prevents release of com object from memory and creates a zombie process.

[mhammond]

Sorry for the delay, and sob :) 301 had a regression reported in #1753, which regressed you. Do you have any suggestions what should change in the new implementation? If it's just __call__, I think it would be safe to revert just that back - or is there a better way to "inject" all those names?

[fzumstein]

Hi @mhammond, thanks for looking into this! While we wait for @panda-34's answer, I can offer you to test your suggested changes. Feel free to point me to a branch or also just a snippet with your minimal suggested changes and I can let you know if that already solves the issue.

[mhammond]

Try removing "__call__" from the list here, and add to the object:

    def __call__(self, *args, **kwargs):
        return self.__dict__["_dispobj_"].__call__(*args, **kwargs)

[fzumstein]

Thanks for the hint! I've tried it but could only make it work properly by also doing the same for str, int and iter:

class CoClassBaseClass:
    def __init__(self, oobj=None):
        if oobj is None:
            oobj = pythoncom.new(self.CLSID)
        dispobj = self.__dict__["_dispobj_"] = self.default_interface(oobj)
        # See comments below re the special methods.
        for maybe in [
            "__len__",
            "__nonzero__",
        ]:
            if hasattr(dispobj, maybe):
                setattr(self, maybe, getattr(self, "__maybe" + maybe))

    def __call__(self, *args, **kwargs):
        return self.__dict__["_dispobj_"].__call__(*args, **kwargs)

    def __str__(self, *args):
        return self.__dict__["_dispobj_"].__str__(*args)

    def __int__(self, *args):
        return self.__dict__["_dispobj_"].__int__(*args)

    def __iter__(self):
        return self.__dict__["_dispobj_"].__iter__()

[panda-34]

I'm not familiar with internals of either library so I'm no sure what exactly is a problem here but normally wrappers should just redirect implicit calls of special methods on wrapped objects, i.e.:

	def __call__(self, *args, **kwargs):
		return self.__dict__["_dispobj_"](*args, **kwargs)

	def __str__(self, *args):
		return str(self.__dict__["_dispobj_"])

	def __int__(self, *args):
		return int(self.__dict__["_dispobj_"])

	def __iter__(self):
		return iter(self.__dict__["_dispobj_"])

	def __len__(self):
		return len(self.__dict__["_dispobj_"])

	def __bool__(self):
		return bool(self.__dict__["_dispobj_"]) 

Note also that instead of __bool__ you've implemented __nonzero__ which is from python 2 and doesn't exist in python 3 and that was the actual cause of #1753 that you mentioned
So in essence you should revert to previous behavior and add missing __bool__ to prevent #1753.
Whether calls should be implicit (as in my code) or explicit (as in your old code) is only important if dispobj could override special methods on the instance which I'm pretty sure it shouldn't.