[Python-Dev] Death to WITH_CYCLE_GC

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


[MAL]
> Then why do we have a switch to optionally remove the Unicode
> support ?

I don't know, although I've asked that question myself.  People used to be
frightened of the Unicode database sizes; I'm not sure they are anymore.

> or for disabling interning of strings ?

There is no such switch now.  There used to be one.  Ditto for whether to
cache hash values.  Ditto whether to "cache-align" hash table entries.  At
the time those were nuked, Guido also said he wanted COUNT_ALLOCS to
disappear (and to act as if it were always #define'd in a Py_TRACE_REFS
build), but nobody has gotten to that yet.

> or for caching small integers ?

There isn't a switch for that either, although there are two undocumented
symbols you can #define such that if their sum is <= 0, small ints waste
*more* memory than if you leave the code alone.  There's no way to disable
the unbounded and immortal int free list, and never was.

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

>> 6, give or take.

> 6 what ? snakes, rabbits, swallows ?

You asked an unanswerable (not to mention unparseable) question, I gave a
useless yet accurate answer -- if you can rephrase your question in a way
that can be answered, attach whatever units you need to make 6 exactly
correct <wink>.  Although note that since WITH_CYCLE_GC has been #define'd
by default since it was introduced, removing its #ifdefery would have no
effect on default builds.

> I'm missing a concise concept here :-)
>
> If you want to make life hard for people who want to customize
> the interpreter, then you should remove *all* such #ifdefs. If
> not, then having the #ifdefs adds important meta-information
> to the code.

If you don't personally use a specific preprocessor symbol routinely, I
won't accept your bare assertion that it makes life easier for anyone.
Against that, every preprocessor symbol certainly makes it-- a little to a
lot --harder to maintain the code.  We almost never hear from anyone that
these little nightmares are being used; when we do hear about them, it's
almost always from a dabbler who "just tried it" and then complains because
Python no longer works (from won't compile to segfaults).  Fixing unused
code is a waste of time; I won't do it anymore, but I will devote time to
getting rid of unused code.