Add a stream parameter to gc.set_debug

[nicdumz]

BPO	5851
Nosy	@birkenfeld, @amauryfa, @pablogsal, @isidentical

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-12-29.18:46:26.316>
created_at = <Date 2009-04-27.06:24:01.893>
labels = ['interpreter-core', 'type-feature']
title = 'Add a stream parameter to gc.set_debug'
updated_at = <Date 2019-12-29.18:46:26.315>
user = 'https://bugs.python.org/nicdumz'

bugs.python.org fields:

activity = <Date 2019-12-29.18:46:26.315>
actor = 'pablogsal'
assignee = 'none'
closed = True
closed_date = <Date 2019-12-29.18:46:26.316>
closer = 'pablogsal'
components = ['Interpreter Core']
creation = <Date 2009-04-27.06:24:01.893>
creator = 'nicdumz'
dependencies = []
files = []
hgrepos = []
issue_num = 5851
keywords = []
message_count = 7.0
messages = ['86647', '88418', '91947', '185428', '358985', '358992', '358999']
nosy_count = 5.0
nosy_names = ['georg.brandl', 'amaury.forgeotdarc', 'nicdumz', 'pablogsal', 'BTaskaya']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue5851'
versions = ['Python 3.4']

[nicdumz]

Hello!

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.

Thanks!

[amauryfa]

Would you like to work on a patch?

[nicdumz]

Sure, I'd be happy to contribute a patch.

I uploaded a patch on Rietveld, at http://codereview.appspot.com/110078

Let me know how it looks.

[birkenfeld]

Patch would need to be updated for Python 3.4. (Please also upload it to this issue.)

[isidentical]

@nicdumz are you still interested in this issue?

[pablogsal]

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).

[pablogsal]

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.