On Fri, Sep 10, 2010 at 14:55, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
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.
Sure, but exceptions printed out by a __del__ method during interpreter shutdown are not explicitly done as part of the shutdown process, they just happen to typically be triggered by a shutdown. This gc info, OTOH, is explicitly debugging information that is only printed out (typically) at shutdown and thus at a point where it will no longer effect semantics or the performance of the application. So I view this as entirely debugging information and thus in no way critical for a user to know about. -Brett
+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. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org