Tracing not disabled in generator when the system trace function returns None.

[xdegaye]

BPO	20040
Nosy	@pitrou, @nedbat, @xdegaye, @serhiy-storchaka
Files	tracer.py

^{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 = None
created_at = <Date 2013-12-21.13:55:53.784>
labels = ['interpreter-core', 'type-bug']
title = 'Tracing not disabled in generator when the system trace function returns None.'
updated_at = <Date 2013-12-21.14:21:32.455>
user = 'https://github.com/xdegaye'

bugs.python.org fields:

activity = <Date 2013-12-21.14:21:32.455>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2013-12-21.13:55:53.784>
creator = 'xdegaye'
dependencies = []
files = ['33244']
hgrepos = []
issue_num = 20040
keywords = []
message_count = 2.0
messages = ['206734', '206738']
nosy_count = 4.0
nosy_names = ['pitrou', 'nedbat', 'xdegaye', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue20040'
versions = ['Python 3.4']

[xdegaye]

The sys.settrace documentation states:
The trace function is invoked (with event set to 'call') whenever a new local scope is entered;
it should return a reference to a local trace function to be used that scope, or None if the scope shouldn’t be traced.

But when tracing a generator, 'line' events may be traced even though tracing has been disabled by
returning None at the 'call' event. Run the attached tracer.py with 0 as argument and see that
tracing does not stop as it should when count is 1:
$ python tracer.py 0
call gen with count 0
line
line
return
call gen with count 1
returning None: the scope shouldn’t be traced
line
return

However, when tracer.py is run with 1 as argument, tracing is (correctly) disabled when count is 1
and 2. This problem is closely related to bpo-11992.
The dispatch_call() method of Bdb in the bdb module is broken when the frame is a generator and the
previous command is next, until or return (and when this problem is fixed).

[xdegaye]

A patch is proposed in bpo-20041.

[iritkatriel]

CC @gaogaotiantian

[gaogaotiantian]

I am on the fence on this one. I understand the issue, but I think the current behavior conforms to our documentation.

The documentation (as quoted) is:

The trace function is invoked (with event set to 'call') whenever a new local scope is entered; it should return a reference to a local trace function to be used for the new scope, or None if the scope shouldn’t be traced.

Notice the part "whenever a new local scope is entered" - that's the condition for the whole sentence. call event is not the deterministic factor, we only guarantee that every time a new local scope is entered, a call event will be triggered, that's different. We can surely have call events when an existing local scope is entered and returning None means nothing in that case.

I think generators fall into this category - it's not a new local scope, so the value it returns has nothing to do with tracing.