On 2019-10-07 08:04, Geoff Bache wrote:
It's possible. Our embedding code is fairly simple and we've tried to
encapsulate all the DECREFing in resource objects, i.e. that do DECREF
in their destructor when they go out of scope. We hoped this would
minimise this sort of problem.
The C++ calling code essentially tries to call progwrapper.prog with a
dictionary as arguments, and looks like
GilStateHolder pyStateHolder;
PyRefHolder module(PyImport_ImportModule("progwrapper"));
if (module._ref)
{
PyXRefHolder func(PyObject_GetAttrString(module._ref, "prog"));
PyXRefHolder pyArgs(PyTuple_New(1));
PyXRefHolder pyDict(convertDictForPython(dictIn));
PyTuple_SetItem(pyArgs._ref, 0, pyDict._ref);
|Do you DECREF pyDict._ref later on? I ask because PyTuple_SetItem
steals a reference.|
|Many other functions that "store" an object, such as PyList_Append,
INCREF to retain the stored object, but PyTuple_SetItem doesn't.|
||
PyRefHolder pyRet(PyObject_CallObject(func._ref, pyArgs._ref));
if (pyRet._ref != NULL)
{
addPythonValuesToDict(pyRet._ref, theDict);
...
where GilStateHolder, PyRefHolder etc are such resource objects as
described above, wrapping round the PyObject pointers etc.
[snip]
--
https://mail.python.org/mailman/listinfo/python-list
