homepage

PyModule_AddObject() has weird and counterintuitive behavior. It steals a reference only on success. The caller is responsible to decref it on error. This behavior was not documented and inconsistent with the behavior of other functions stealing a reference (PyList_SetItem() and PyTuple_SetItem()). Seems most developers don't use this function correctly, since only in few places in the stdlib a reference is decrefed explicitly after PyModule_AddObject() failure.
This weird behavior was first reported in issue1782, and changing it was proposed. Related bugs in PyModule_AddIntConstant() and PyModule_AddStringConstant() were fixed, but the behavior of PyModule_AddObject() was not changed and not documented.
This issue is opened for gradual changing the behavior of PyModule_AddObject(). Proposed patch introduces new macros PY_MODULE_ADDOBJECT_CLEAN that controls the behavior of PyModule_AddObject() as PY_SSIZE_T_CLEAN controls the behavior of PyArg_Parse* functions. If the macro is defined before including "Python.h", PyModule_AddObject() steals a reference unconditionally. Otherwise it steals a reference only on success, and the caller is responsible for decref'ing it on error (current behavior). This needs minimal changes to source code if PyModule_AddObject() was used incorrectly (i.e. as documented), and keep the code that explicitly decref a reference after PyModule_AddObject() working correctly.
Use of PyModule_AddObject() without defining PY_MODULE_ADDOBJECT_CLEAN is declared deprecated (or we can defer this to 3.7). In the distant future (after dropping the support of 2.7) the old behavior will be dropped.
See also a discussion on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/157545 .

I think the current behavior is good for error handling by goto,
which is common for module initialization.
Please don't change this.

Idiomatic code is
 if (PyModule_AddObject(module, "name", create_new_object()) < 0)
 goto error;
If you already have a reference and need to use it later:
 obj = create_new_object();
 ... /* use obj */
 Py_INCREF();
 if (PyModule_AddObject(module, "name", create_new_object()) < 0)
 goto error;
 ... /* use obj */
 Py_DECREF(obj);
error:
 Py_XDECREF(obj);
Many current code use above idioms, but it doesn't work as expected.
It is almost impossible to write correct code with current behavior. And _decimal.c is not an exception, it has leaks.

Your definition of correctness is very odd. The "leaks" you are talking
about are single references in case of a module initialization failure,
in which case you are likely to have much bigger problems.
Please take _decimal out of this patch, it's a waste of time.

It seems that the patch also introduces a segfault if PyLong_FromSsize_t() returns NULL.

> It seems that the patch also introduces a segfault if PyLong_FromSsize_t() returns NULL.
Good catch Stefan! Py_XDECREF ahould be used instead of Py_DECREF in _PyModule_AddObject().

Removed changes in _decimal.c and deprecation. Used Py_XDECREF in _PyModule_AddObject().

Serhiy, I'm sorry that I overreacted here. You're doing great work for
Python -- we just happen to disagree on this one particular issue.
I think there were some proponents on python-dev, perhaps they'll show
up and discuss the details.

Since https://github.com/python/cpython/pull/23122, there is PyModule_AddObjectRef doesn't steal a reference.
PyModule_AddObject is discouraged in the docs, but not formally deprecated. (As Stefan notes, the leaks are single references in case of a module initialization failure -- the cost of using the API incorrectly is very small; requiring everyone to change their code because it was possible to misuse it is overkill.)
See https://docs.python.org/3.10/c-api/module.html#c.PyModule_AddObjectRef
I think this is enough to close the issue.