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. Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list