Puzzling behaviour of Py_IncRef

[Barry Scott]

> On 27 Jan 2022, at 07:46, Tony Flury <tony.flury at btinternet.com> wrote:
> 
> 
> On 26/01/2022 22:41, Barry wrote:
>> 
>> 
>> Run python and your code under a debugger and check the ref count of the object as you step through the code.
>> 
>> Don’t just step through your code but also step through the C python code.
>> That will allow you to see how this works at a low level.
>> Setting a watch point on the ref count will allow you run the code and just break as the ref count changes.
>> 
>> That is what I do when a see odd c api behaviour.
>> 
>> Barry
> 
> 
> Thanks - I have tried a few times on a few projects to run a debugger in mixed language mode and never had any success.
> 
> I will have to try again.

You mean debugging Python and C/C++? In this case your python code is a simple test script and it's C that you care about.
Should not be difficult. I tend to use linux as my lead debug platform as its the easiest to work with. But Windows and macOS
also have very good debuggers.

Barry

> 
> 
>>> As posted in the original message - immediately before the call to the C function/method sys.getrefcount reports the count to be 2 (meaning it is actually a 1).
>>> 
>>> Inside the C function the ref count is incremented and the Py_REFCNT macro reports the count as 3 inside the C function as expected (1 for the name in the Python code, 1 for the argument as passed to the C function, and 1 for the increment), so outside the function one would expect the ref count to now be 2 (since the reference caused by calling the function is then reversed).
>>> 
>>> However - Immediately outside the C function and back in the Python code sys.getrefcount reports the count to be 2 again - meaning it is now really 1. So that means that the refcount has been decremented twice in-between the return of the C function and the execution of the immediate next python statement. I understand one of those decrements - the parameter's ref count is incremented on the way in so the same object is decremented on the way out (so that calls don't leak references) but I don't understand where the second decrement is coming from.
>>> 
>>> Again there is nothing in the Python code that would cause that decrement - the decrement behavior is in the Python runtime.
>>> 
>>>>> -- 
>>>>> Anthony Flury
>>>>> email :anthony.flury at btinternet.com
>>>>> 
>>>>> -- 
>>>>> https://mail.python.org/mailman/listinfo/python-list
>>>>> 
>>> -- 
>>> Anthony Flury
>>> email :anthony.flury at btinternet.com
> 
> -- 
> Anthony Flury
> email : anthony.flury at btinternet.com
>