This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Eric Cousineau
Recipients Eric Cousineau, docs@python, pitrou
Date 2020-04-09.14:55:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1586444148.18.0.625815694597.issue32377@roundup.psfhosted.org>
In-reply-to
Content
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 :(
History
Date User Action Args
2020-04-09 14:55:48Eric Cousineausetrecipients: + Eric Cousineau, pitrou, docs@python
2020-04-09 14:55:48Eric Cousineausetmessageid: <1586444148.18.0.625815694597.issue32377@roundup.psfhosted.org>
2020-04-09 14:55:48Eric Cousineaulinkissue32377 messages
2020-04-09 14:55:47Eric Cousineaucreate