There's a comment in siplib.c:5300ish in the sip_api_is_py_method function that I'll reproduce here:
/* * Note that the callable is never garbage collected. The main * reason for this is that it's not possible to get hold of the * method cache without make incompatible changes to the SIP * API, particularly to support the cyclic garbage collector. * It would be a lot easier if the cache was held in the * Python object rather than the derived C++ class (and this * function would be passed a cache index instead of a pointer * to the cache entry). Dropping the cache completely should * also be considered which would have the advantage of making * monkey patching predictable. With cyclic garbage collector * support we could also just save a reference to a * reimplementation that was a method rather than save the * separate components, which would also allow a borrowed * reference to the reimplementation to be returned so that the * virtual handler wouldn't need to decrement its reference * count. */ I'm tracking down a memory leak in my app--and I think it's boiling down to a virtual method on one of my classes that has an extra reference, one not coming from any Python object. This virtual method is /bound/, though, so my understanding is that it carries "self" in its im_self attribute and is keeping the rest of my objects alive when they shouldn't be. Should I be worried about that comment--and specifically that objects using virtual methods will leak? Reading the code seems to say otherwise; that the comment is applying to the case when a monkeypatched callable has been set on the class--not when you override a method in a subclass like usual. Phil, do you mind explaining the limitation this comment is describing a bit more? I appreciate any help! _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
