[Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc

[Antoine Pitrou]

On Mon, 1 Jun 2015 17:52:13 +0200
Petr Viktorin <encukou at gmail.com> wrote:
> On Mon, Jun 1, 2015 at 5:33 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Mon, 1 Jun 2015 16:38:35 +0200
> > Petr Viktorin <encukou at gmail.com> wrote:
> [...]
> >> The nice way out would be taking advantage of PEP 442: xxlimited.Xxo
> >> can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the
> >> former of which it needs anyway to behave correctly). Unfortunately,
> >> tp_finalize is not available in the stable ABI (issue24345). I think
> >> it should be added; is it too late for 3.5?
> >
> > Well, but.... the stable ABI is supposed to be a subset of the API
> > that's safe to program against, regardless of the Python version (at
> > least from the point where the stable ABI was introduced).
> 
> That part's not true. From the PEP:
> During evolution of Python, new ABI functions will be added.
> Applications using them will then have a requirement on a minimum
> version of Python; this PEP provides no mechanism for such
> applications to fall back when the Python library is too old.

I think we have been laxist with additions to the stable ABI:
apparently, they should be conditioned on the API version requested by
the user.  For example, in pystate.h:

#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x03030000
/* New in 3.3 */
PyAPI_FUNC(int) PyState_AddModule(PyObject*, struct PyModuleDef*);
PyAPI_FUNC(int) PyState_RemoveModule(struct PyModuleDef*);
#endif

(those were added by Martin, so I assume he knew what he was doing :-))

This way, failing to restrict yourself to a given API version fails at
compile time, not at runtime. However, it's also more work to do so
when adding stuff, which is why we tend to skimp on it.

Regards

Antoine.