Understand CPython's Reference Counting

Reference Counting in CPython

CPython reclaims most objects immediately when their refcount hits zero. Every \`PyObject\` header stores \`ob_refcnt\`; \`Py_INCREF\` and \`Py_DECREF\` adjust it under the GIL.

Cycles and PyGC

Simple refcounting cannot free reference cycles. CPython adds a generational cycle detector for container objects that opt into tracking.

Rules for extension authors:

• Borrowed references: caller still owns the object
• New references: you must \`Py_DECREF\` when done
• Stealing references: callee takes ownership

For example, \`x = [1, 2]; y = [x]; x.append(y)\` creates a cycle only the cyclic GC can break; refcount alone leaves both lists alive forever.

\`\`\`c Py_INCREF(obj); /* use obj */ Py_DECREF(obj); \`\`\`

Design Notes

Container cycles need the cyclic GC even when refcounting handles acyclic graphs. Tune `gc.set_threshold` only after you understand which objects participate in `gc.get_objects` tracking.

For This Exercise

This exercise asks you to explain refcount semantics and cyclic GC's role. You will document when objects free immediately versus when the cycle collector must run.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.