What does gc.get_objects() return?
solipsis at pitrou.net
Mon Mar 17 18:18:05 CET 2014
Chris Angelico <rosuav <at> gmail.com> writes:
> It's not strictly an implementation detail, beyond that there are
> certain optimizations. For instance...
> > For CPython 3.4 I guess strings and other atomic types such as ints are
> > not, as well as raw object() instances. Custom class instances on the other
> > hand seem to be under GC control.
> ... strings and ints should never be listed, and custom objects should
> always be listed, but I'd say the non-tracking of object() would be an
> implementation-specific optimization.
These are all implementation details, tied to the fact that the primary
object reclaim mechanism in CPython is reference counting. Other
implementations may use a full GC and gc.get_objects() may then also
return strings and other "atomic" objects (but the implementation may
also elicit to hack get_objects() in order to closely mimick CPython).
All in all, though, gc.get_objects() is an expensive function call (it
will walk the entire graph of objects tracked by the GC, which can be very
large in non-trivial applications), so it's really only useful for
debugging (and, I'd add, for low-level debugging). In most situations,
gc.get_objects() is certainly the wrong tool to use.
More information about the Python-list