On Thu, Mar 13, 2014 at 8:28 AM, Jurko Gospodnetić <jurko.gospodne...@pke.hr> wrote: > So gc.collect() returns a list of all the objects GC is in charge of, and > which instances are and are not tracked by the GC is, I guess, an > interpreter implementation detail.
I assume you don't mean collect() there, as that returns the amount of garbage that it just collected :) 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. Definitely the non-tracking of a dict of nothing but atomic keys and values would be that. The concept is that the GC tracks (in that sense; everything in CPython is refcounted, but that's not what these functions look at) anything that could be a part of a reference cycle. That's all it concerns itself with, so something that can't have references to arbitrary objects can't possibly be worth tracking. Interestingly, a tuple of integers is tracked: >>> a=1,2,3 >>> gc.is_tracked(a) True So not all optimizations are done that could be done. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
