Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <lfqjgu$kug$1@ger.gmane.org>
References: <lfqcr8$249$1@ger.gmane.org> <5320BD3F.5030509@mrabarnett.plus.com> <lfqjgu$kug$1@ger.gmane.org>
Date: Thu, 13 Mar 2014 08:44:56 +1100
Subject: Re: What does gc.get_objects() return?
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8106.1394660698.18130.python-list@python.org>
Lines: 37
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:68300

On Thu, Mar 13, 2014 at 8:28 AM, Jurko Gospodneti=C4=87
<jurko.gospodnetic@pke.hr> wrote:
>   So gc.collect() returns a list of all the objects GC is in charge of, a=
nd
> 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 oth=
er
> 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=3D1,2,3
>>> gc.is_tracked(a)
True

So not all optimizations are done that could be done.

ChrisA