On Thu, Mar 25, 2021 at 9:01 PM Mark Shannon <m...@hotpy.org> wrote: > Maybe the problem is the term "stealing". > The caller is transferring the reference to the callee. > In some circumstances it can make a lot of sense to do so, since the > caller has probably finished with the reference and the callee needs a > new one.
The problem with both borrowed and stolen references is that they implicitly expose the lifetime of the reference as part of the API. I agree that borrowed references are worse in some sense (there is no way to indicate that one is done with a borrowed reference at all). Stolen references are not great though. As you mention, in theory one can treat the stolen reference as having been DECREF'ed and never use it again, but in practice that's hard to do. When reviewing or writing code, one has to remember precisely which API functions steal a reference. One can no longer reason about whether the reference counting is correct by looking for appropriate DECREF's. It's very hard for tools to help pick up mistakes because the reference was freed -- just not necessarily at the right time. Of course it is hard to avoid these kinds of problems as long as pointers to PyObjects and reference counting are part of the API, but let's not make it more difficult to write correct code unless there is a really big advantage to be had by doing so. I also don't see the rules that Victor is proposing as absolutes. More of a "let's have a big conversation before doing this" kind of rule. - Simon _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CIL7IOCDAQYA6HRJTP3ZCNRGYZWPTFQW/ Code of Conduct: http://python.org/psf/codeofconduct/
