In the docs there is written:
"PyObject_CallObject() is “reference-count-neutral” with respect to its arguments."
This is not correct. Its only reference-count neutral if the call was SUCCESSFUL otherwise the argument is INCREFED! 
Can anyone confirm this?

Cheers Krauzi.

By looking into the source, I found PyObject_CallObject() is “reference-count-neutral” even the call is FAILED, because it will always call Py_DECREF(arg) in the end and in case of exception.

Indeed, every function of the API is consistent in this aspect, success or failure should not make a difference in reference counts.  Do you have an evidence of the contrary?

Note that it's possible that because of the failure, some argument is stored in an exception (maybe indirectly, through the traceback which contains active frames and their local variables), which increases its reference count. Clearing the exception should release the reference.

Yes. I think if the argument object's reference count is increased because of the exception traceback or other cases, it has nothing to do with the PyObject_CallObject itself. Both of the Py_INCREF(arg) and Py_DECREF(arg) will always run once through the PyObject_CallObject() call. 
The “reference-count-neutral” means the code of PyObject_CallObject() itself can guarantee the "reference-count-neutral", but not include the callable called by PyObject_CallObject().

a i think i expressed the problem false. The problem is that the arg (which is a tuple here) is correctly decremented and thus the reference counts are OK. BUT: The objects INSIDE the tuple are NOT correctly decremented. This is the code i've used:
C++ Program: http://www.copypastecode.com/26047/
Python Script imported by it: http://www.copypastecode.com/26051/
Now the results:
With raise in python script:
http://img251.imageshack.us/img251/997/witherror.jpg
and with uncommented "raise":
http://img256.imageshack.us/img256/2818/noerror.jpg

Hope its now clear.

Krauzi

Yes, I think what I wrote above applies here: the string is stored in the "args" variable. When the exception is raised, the traceback contains the *live* frame objects, with position in the bytecode and all local variables. This allows post-mortem debugging, for example.

Try calling PyErr_PrintEx(0) instead of PyErr_Print(), this should clear the exception state without storing it in sys.last_traceback, and the reference will decrease.

I don't think this needs to be kept open.