On Fri, Sep 10, 2010 at 3:32 PM, Georg Brandl
<g.brandl@gmx.net> wrote:
IMO this runs contrary to the decision we made when DeprecationWarnings were
made silent by default: it spews messages not only at developers, but also at
users, who don't need it and probably are going to be quite confused by it,
assuming it came from their console application (imagine Mercurial printing
this).
A non-empty gc.garbage often indicates that there is a bug in the program and that it is probably leaking memory [1]. That's a little different from a DeprecationWarning which doesn'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.
+1 on adding a way to enable/disable the feature.
-1 on removing the feature
-0 on making it disabled by default
[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.