GeezerVison

for frame, *unused in inspect.getouterframes(inspect.currentframe()):

I don't like this hack to get frame object for module...
But I don't know is there any way.
I'm not expert of inspect and pdb.

I'm afraid this test is relying implementation detail.
Doesn't #46 affects this? Is this test passes on other Python implementations like PyPy or micropython?

What implementation detail ?
The Python implementations like PyPy follow also the normative description of co_lnotab. I may be wrong, but differences in the definitions of the structure of the AST between those implementations should not bear any impact on the definition of the structure of co_lnotab.

As a side note, offsets increase monotonically so min_offset is the first offset yielded by findlinestarts() and max_offset is the last one (no need to invoke min() or max()).

I didn't research deeply, I just worried. So if PyPy passes this, it's OK.

I think attributes of Python's code object is implementation detail, even though PyPy follows.
But it's not big problem until there are some Python implementation having different code implementation.

I have started a discussion on python-dev about attributes of Python code objects being implementation detail.

@methane
Assuming now that the specification of co_lnotab is an implementation detail, then the pdb and inspect modules from the CPython standard library may fail to run on a new Python implementation that does not follow the CPython co_lnotab specification. So why do you want to constrain test_pdb to run on this Python implementation when the pdb and inspect modules themselves would not ?

@xdegaye I didn't say "I want to do ...". I was asked to review, and leave comment what I feel.
I didn't say LGTM or "change required".

Please ignore me when my comment doesn't make sense for you.
I'm not familiar with this area.

I don't like test relying on outer frame.
I like test which doesn't relying test runner implementation.

But documentation says that whitebox tests are preferred

"whitebox test" is relying on implementation of test target, not test runner.

What is module_frame here? Isn't it relying on test runner?
It can be changed even if pdb and test_pdb is not changed.

So I prefer creating module frame in this test, not capturing from caller of this test.

BTW, is there any difference between module frame and other frames from pdb's point of view?
If there is no difference, function frame is far easier to create, maybe.

In this case I need specifically module frame(as you can see from pdb code itself) and it seems like it doesn't matter which module frame it will be. Can you please show how to create it manually?

frame = inspect.currentframe()

frame must be current test's frame. caller's frame shouldn't affects this test.

It won't be module frame.

Ah, I'm sorry. I misread "I need" as "I don't need".

Now I read pdb.getsourcelines().
If I'm correct, do you want to test this one line: return lines, 1?

I don't know way to create module frame which is simple enough to test such simple one line.

Yes, I would like it to be tested. Initially, when I've seen test coverage of stdlib I wanted to write some tests to improve it. Now it seems like tough task, because it is not even clear who should approve my PRs. If I address all comments here and in bpo, whom can I ask to approve my PR?