GeezerVison

This might not always work:

>>> def f():
...    yield 42
... 
>>> dis.dis(f)
   1           0 RETURN_GENERATOR

None           2 POP_TOP

   1           4 RESUME                   0

   2           6 LOAD_CONST               1 (42)
               8 YIELD_VALUE              1
              10 RESUME                   1
              12 POP_TOP
              14 RETURN_CONST             0 (None)

None     >>   16 CALL_INTRINSIC_1         3 (INTRINSIC_STOPITERATION_ERROR)
              18 RERAISE                  1
ExceptionTable:
  4 to 14 -> 16 [0] lasti
>>> 

True - it's not "worse" than the current solution though.

Actually would it be more reasonable to use the line number of the instruction after RESUME?

Now that I think about it, generators probabaly have more problems with function breakpoints - when I set a breakpoint on a generator function, I'd hope that the breakpoint is hit every time the function is entered right? And pdb is not able to do that now - it stores the line that executed first and break on that line. We could potentially enter the generator on a different line. So the problem is more serious already on generators.

Actually would it be more reasonable to use the line number of the instruction after RESUME?

I think the code object already has that in a field called _co_firsttraceable.

Now that I think about it, generators probabaly have more problems with function breakpoints

I can believe that. When you call a generator function it creates a generator object and returns it. Then you repeatedly call the generator object (which executes the same code, past the point of the RETURN_GENERATOR).

I think the code object already has that in a field called _co_firsttraceable.

Yes and I don't think it was exposed to Python level.

I can believe that. When you call a generator function it creates a generator object and returns it. Then you repeatedly call the generator object (which executes the same code, past the point of the RETURN_GENERATOR).

I caused an assertion error when I was trying to test a little bit more with generators - I'll investigate into it.

From a user's point, what would be the expected behavior if they set a breakpoint to the generator function? Do they want a break when the generator is being created (so actually RETURN_GENERATOR)? That's a valid call. Or do they want a break when the "first time" the generator is executed? Or every time the generator is executed? Those are three different behaviors and the third one has issues with display the line number.

I would expect it to be the first time the generator is executed. The next time it will start executing after some yield, and that's not the first line of the function.

In that case, we can use the RESUME method I mentioned above (which I think is basically how _co_firsttraceable works). Or do you think we should expose that member to Python?

I think you can re-implement it. As long as we have a test that will give us a heads up when it needs to change it should be ok.

@markshannon do you agree?

I updated the line searching method to use the instruction after RESUME. Also a generator test case is added.

There is one thing that I realized - if you do break func before the func is defined(evaluated), you'll still get a line number at the function definition - it uses re to find the function.

Is it better to have a consistant wrong answer, or a partially correct one?