Eric Cousineau <eric.cousineau@tri.global> added the comment:
Super late response, but for this part: > Well... perhaps you could create another PyObject (it's just a wrapper, > right?) since the old one doesn't have any outside references to it > remaining. In certain cases, yes, that would be the case. I do have unittests that (hackily) check `id(o)` before and after resurrection by using a `weakref`, so I could relax that contract. However, in other cases, the "wrapper" object in Python is actually a C++ base class that has been derived from in Python. If ownership of the C++ instance (which should more-or-less own the Python portion) goes solely to C++, then the Python portion could be garbage collected, and you get a sort-of slicing effect: https://github.com/pybind/pybind11/issues/1145 Granted, within this web of issues, one alternative is to always extend the lifetime of the Python object by the C++ portion. However, that creates a (opaque?) reference cycle between C++ and CPython, so I am a bit afraid of what that would do. I would prefer to make memory management conservative if possible. Or rather: It's something cool to try out, but I have not yet had time to dig in :( ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32377> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
