{Tim]
> So, on what principled basis do we exempt, say, ints from
> participating in cyclic GC too?
{Pablo]
> In this case, the int object doesn't have a reference to its type because is
> not a heap type
> so that's fine.
That baffled me at first, because _every_ object contains a pointer to
its type object. But in the case of int, that doesn't count as "having
a reference" to you, probably because of this:
static inline void
_PyObject_Init(PyObject *op, PyTypeObject *typeobj)
{
assert(op != NULL);
Py_SET_TYPE(op, typeobj);
if (_PyType_HasFeature(typeobj, Py_TPFLAGS_HEAPTYPE)) {
Py_INCREF(typeobj);
}
_Py_NewReference(op);
}
So, ya, an int does have a pointer to its type object, but it's
effectively exempted from even the refcounting system. That makes the
int type object effectively immortal, which would in turn make any
otherwise-dead cycle reachable from the int type object immortal too.
So no point in CPython'a peculiar form of GC chasing it (unlike, e.g.,
mark-&-sweep, CPython doesn't try to find the set of live objects).
This isn't an entirely happy state of affairs ;-)
_______________________________________________
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/OUO6OEW7FEZZ2HJMIISEHEEMXXDJJWEE/
Code of Conduct: https://www.python.org/psf/codeofconduct/
