<div class="gmail_quote">On Fri, Sep 10, 2010 at 3:32 PM, Georg Brandl <span dir="ltr">&lt;<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
IMO this runs contrary to the decision we made when DeprecationWarnings were<br>
made silent by default: it spews messages not only at developers, but also at<br>
users, who don&#39;t need it and probably are going to be quite confused by it,<br>
assuming it came from their console application (imagine Mercurial printing<br>
this).<br></blockquote><div><br>A non-empty gc.garbage often indicates that there is a bug in the program and that it is probably leaking memory [1].  That&#39;s a little different from a DeprecationWarning which doesn&#39;t indicate a bug; it just indicates that the program might not run correctly using a future version of Python.  I think a better comparison would be with exceptions throw from a __del__, which (as far as I know) are still printed to the console.<br>
<br>+1 on adding a way to enable/disable the feature.<br>-1 on removing the feature<br>-0 on making it disabled by default<br><br>[1] I know that some large, long-running programs periodically check gc.garbage and carefully choose where to break cycles, but those are the exception and not the rule.<br>
</div></div><div style="margin: 2em 0pt;" name="sig_2341e11ee1">--<br>
Daniel Stutzbach, Ph.D.<br>
President, <a href="http://stutzbachenterprises.com">Stutzbach Enterprises, LLC</a>
</div><br>