<br><br><div class="gmail_quote">On Wed, Jun 4, 2008 at 7:32 PM, Andrew MacIntyre &lt;<a href="mailto:andymac@bullseye.apana.org.au">andymac@bullseye.apana.org.au</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are 2 disparate approaches to clearing/compacting free lists for<br>
basic types:<br>
- APIs of the form Py&lt;type&gt;_ClearFreeList() called from gc.collect()<br>
 &nbsp;[class, frame, method, tuple &amp; unicode types];<br>
- APIs of the form Py&lt;type&gt;_CompactFreeList() called from<br>
 &nbsp;sys._compact_freelists() &nbsp;[int &amp; float types];<br>
<br>
Both approaches are new for 2.6 &amp; 3.0.<br>
<br>
The patch at <a href="http://bugs.python.org/issue2862" target="_blank">http://bugs.python.org/issue2862</a> is geared towards bring<br>
the int/float free list management into line with the others.<br>
<br>
The patch at <a href="http://bugs.python.org/issue3029" target="_blank">http://bugs.python.org/issue3029</a> adds free list management<br>
to the dict, list &amp; set types. &nbsp;The value of this is probably minor,<br>
and this patch is thus not significant in its own right other than for<br>
consistency.<br>
<br>
However Raymond&#39;s comment to issue 3029 that the management routines<br>
shouldn&#39;t be public APIs is IMO important (&amp; I happen to agree).<br>
<br>
It would be nice to reduce the 2 approaches to one.<br>
<br>
I would rather the gc.collect() approach, as this seems to be more<br>
obvious to many users who have gone looking for free list management in<br>
prior versions, however my opinion isn&#39;t particularly valuable on this.<br>
<br>
Can this be resolved for 2.6/3.0?<br>
</blockquote><div><br>I agree with the gc.collect approach taken in your issue2862 patch.&nbsp; Barring any objections, I suggest we accept it and will commit it in the next couple days.<br><br>-gps<br><br></div></div>