Due to historical reasons, sys.settrace issues a line event for for loops even if the jump target is on the same line:

# 10 line events on this line
for _ in range(10): pass

We don't want to touch this behavior, because it's been like this for like forever.

However, it's not desirable to pdb. When the user does next or step command, they want to step over this line and reach the next line.

Our documentation also clearly states such behavior:

s(tep)
Execute the current line, stop at the first possible occasion (either in a function that is called or on the next line in the current function).

n(ext)
Continue execution until the next line in the current function is reached or it returns. (The difference between next and step is that step stops inside a called function, while next executes called functions at (nearly) full speed, only stopping at the next line in the current function.)

So I consider the current behavior as a bug, which we should fix.

A thought might be - why don't we check this in stop_here? The reason is because dispatch_exception also uses stop_here and we should trigger user_exception even if it's on the same line.

An extra check in dispatch_line is the cleanest way I can think of to make this happen - only line events should be dealt with. We don't need to worry about the extra reference to a frame because the eventual continue (or anything other than step or next) will clear this reference.

Let me know if anyone has a better idea of how to implement this.

• Issue: pdb: 'n' and 'until' do not skip list comprehension after setting a breakpoint #136057