[Python-Dev] Death to WITH_CYCLE_GC

Tim Peters tim@zope.com
Wed, 3 Jul 2002 12:56:17 -0400


[M.-A. Lemburg]
> Hmm, isn't the idea of having compile time options to give
> people a chance to eliminate the feature altogether ?

That may be idea for some symbols; e.g., I suppose HAVE_UNICODE is of that
nature, although PythonLabs never tests with that disabled either.

WITH_CYCLE_GC wasn't of that nature.  Like pymalloc before it, cyclic gc was
*thought* to be such a large change that it would be prudent to leave cyclic
gc off for a release, but give adventurous people a symbol they could use to
try it.  WITH_CYCLE_GC was enabled by default in the first alpha release to
get it some exercise.  That didn't turn up any significant problems, so we
left it on in the next alpha release too.  Still no problems, so we left it
on for all the alphas releases.  Still no problems, so we left it on for all
the beta releases.  Still no problems, so we concluded "screw this, let's
leave it enabled for the final release too".  So the purpose for which
WITH_CYCLE_GC was introduced went away before anyone had a chance to use it
for that purpose.

> I'm thinking in terms of memory footprint of the running
> interpreter and its binary. Platforms like e.g. Palm
> or Pocket PC are very touchy about this. Embedded devices
> even more.

I don't buy this.  I don't work on embedded devices in this incarnation, and
from what I've seen the people who do aren't helped at all by people who
don't guessing about what they might need.  If people on embedded devices
need help in the core, they can speak for themselves, and get the help they
*really* need.

> How much memory footprint would removing the #ifdefs
> cause on average ?

6, give or take.