The attached patch adds free list clearing routines for the list, dict &
set objects.  These objects are the only ones with free lists that don't
already have some form of free list management API.  This patch
complements the patch in issue 2862.

What is the point of expanding the C API for clearing individual 
types.  Isn't the single Fini function sufficient to clear them all?

Make the approaches consistent seems like a reasonable goal, but why 
did you choose the path where everything has its own clearing function 
instead of one to bind the all?  What apps need this?

Freelist clearing functions for int and float were added by Christian,
and made available to Python code via a function in the sys module.  I
don't know who added the freelist clearing functions for the class,
frame, method, tuple and unicode objects, but they are called by
gc.collect().

Because the freelist implementations are all static to the relevant type
source files, functions within each object source file seem a reasonable
way of implementing the required functionality.

I don't see the need for them to be part of the public API, but I framed
this patch to fit in with what's already in place.

It is likely that the functionality of this patch is of minor value, and
can thus be rejected.

Indeed, I experimented with ripping out all freelists and making sure
that all types used PyMalloc, and the resulting interpreter is about
6-8% slower on a pybench run (FreeBSD 7.0, gcc 4.2.1, 6% slower on
32bit, 8% slower on 64bit, 64bit is ~15% faster than 32bit in either
case) than the trunk (r63501).  Individual micro-benchmarks in pybench
show 15-30% variations between the freelist & no freelist, but this
doesn't seem to significantly affect the running of the whole benchmark.

Issue 2862 is more important IMO, as the current situation has 2
different approaches to accessing freelist management, where I believe
there should only be 1.

> I don't see the need for them to be part of the 
> public API, but I framed this patch to fit in 
> with what's already in place.

These should not be part of the public API; otherwise,
we lock-in the freelisting implementation detail and
cannot readily change it (since some C code may come
to rely on the new functions).

everyone seems to be in agreement that this patch is a bad idea.  closing.