Just my code exclusions will require a double step to step into excluded code

[rchiodo]

Environment data

• DEBUGPY version: 1.0.b8
• OS and version: Windows 10
• Python version (& distribution if applicable, e.g. Anaconda): XXX
• Using VS Code or Visual Studio: VS Code

Steps to reproduce:

Create three files:
baz.py

def baz():
   print('baz')

foo.py:

def foo():
   print('foo')

test.py:

import foo
import baz
print('start')
foo.foo()
baz.baz()
print('stop')

Setup debug config to exclude baz, but include foo and test.
Debug test.py and step into every call.

Actual behavior

It takes two steps to get over baz.baz()

Expected behavior

It takes one step.

[rchiodo]

Same thing happens on the last line of a file if you step into it (F11). It will step twice.

[fabioz]

As a note, the tricky thing is that on a step in, the debugger actually stops when doing a return from a previous call (because on some situations if we don't stop at the return event we may end up never stopping at all), so, inside the debugger what's happening is that the step in skips lots of code and steps at the point where it'd get back to user code (which in this case is the same place).

This needs some investigation to check how we could handle both scenarios.

[int19h]

We've had half-steps before in some cases. We should fix this if it's straightforward, but given that the workaround is also trivial (just step again!), it's not worth it spending too much time on this.

[greazer]

This will actually result in a pretty poor experience for our run-by-line scenario. I'd really like to get this fixed for the first release of that feature (June)

[int19h]

Just this particular case? Keep in mind that there will be others in which step doesn't actually step over the entire line.

[greazer]

I think mainly this case, though I'm interested to know what other cases there might be.

The idea here is that run-by-line is super simple and highly geared toward executing each line of only the current cell. The data scientists who make use of this don't have a notion of what step-into vs step-over is, so when they experience this strange behavior, they won't likely be able to make sense of what might be happening under the covers. Even as a virtual debugger expert, I found it disconcerting myself as I was stepping with the button. Sometimes, I would click and nothing would happen. But I wasn't sure if it was because I didn't actually click? or whether I clicked and the line did move I just didn't notice? Or whether it just didn't work? When I'm focused on the variables window to watch the the value change or I move your eyes to the button to click (and take them off the code), I necessarily become partially distracted from what exactly I might be stepping and am focused on seeing a change based on what I expect the step to do. However, when I step and nothing occurs, I'm left wondering what just happened. It breaks my concentration about what I was trying to understand about the state of my program after I step.

If this truly is going to be risky to fix or tricky to deal with then I guess it would be ok to at least ship this way initially. But if getting at least this bug's repro scenario to work as desired is relatively safe, then I would really like to see it happen. :)

[fabioz]

I'll take a look into it as my next task then.

[int19h]

@fabioz, can you do some research on what it'd take to fix first? If takes a major change to the stepping code to handle it well in some scenarios, we'll need to balance more polished UX against the amount of work necessary to make that happen, and potential destabilization. For the ones that have an easy fix - and hopefully this particular repro is one of them! - let's just go ahead and fix them.