This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add a stream parameter to gc.set_debug
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.4
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, amaury.forgeotdarc, georg.brandl, nicdumz, pablogsal
Priority: normal Keywords:

Created on 2009-04-27 06:24 by nicdumz, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg86647 - (view) Author: Nicolas Dumazet (nicdumz) Date: 2009-04-27 06:24

gc.set_debug is provided to help debugging a leaking program. That tool
can be very useful indeed. 

Debugging information, however, is written to sys.stderr, and there are
cases where this behavior can be a problem: chances are that stderr can
be already used to output other information.

Currently, to debug a verbose program writing to stderr, one has to
either first reduce/suppress the stderr output noise from its program
before activating set_debug, OR has to redirect the whole mixed stderr
output, and filter it afterwards. 

I'd like very much the possibility to configure myself where the gc
debugger will write its output.

My suggestion would be to have set_debug converted from set_debug(flags)
to set_debug(flags, stream=sys.stderr), stream being any valid file
object, but any solution allowing me to customize the output target of
the gc debugger would be welcome.

msg88418 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-05-27 14:00
Would you like to work on a patch?
msg91947 - (view) Author: Nicolas Dumazet (nicdumz) Date: 2009-08-24 23:10
Sure, I'd be happy to contribute a patch.

I uploaded a patch on Rietveld, at

Let me know how it looks.
msg185428 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-03-28 10:39
Patch would need to be updated for Python 3.4.  (Please also upload it to this issue.)
msg358985 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2019-12-29 09:40
@nicdumz are you still interested in this issue?
msg358992 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-12-29 16:56
I am not convinced about this. One of the problems I dislike is that the gc will take permanent ownership of the file descriptor (so is basically leaked). Is also not clear how this will behave during the delicate stages of finalization (the stream object provided can be anything that we have no control over during finalization) and also, it makes it a bit riskier as this can execute arbitrary python code in the middle of the gc.

On the other hand, is possible to use the gc callbacks to gather similar statistics about collections doing whatever you need there (like writing to file descriptors and the such).
msg358999 - (view) Author: Pablo Galindo Salgado (pablogsal) * (Python committer) Date: 2019-12-29 18:46
I am going to close this for now as per my last comment (I think gc callbacks are best suited for custom statistics and custom behaviour when emitting the statistics - and more importantly, safer -) but feel free to re-open if you still think we didn't consider something important.
Date User Action Args
2022-04-11 14:56:48adminsetgithub: 50101
2019-12-29 18:46:26pablogsalsetstatus: open -> closed
resolution: rejected
messages: + msg358999

stage: resolved
2019-12-29 16:56:50pablogsalsetnosy: + pablogsal
messages: + msg358992
2019-12-29 09:40:00BTaskayasetnosy: + BTaskaya
messages: + msg358985
2013-03-28 10:39:43georg.brandlsetnosy: + georg.brandl

messages: + msg185428
versions: + Python 3.4, - Python 2.7
2009-08-24 23:10:52nicdumzsetmessages: + msg91947
2009-05-27 14:00:39amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg88418
components: + Interpreter Core, - Extension Modules
2009-04-27 06:24:01nicdumzcreate