Introduces more interactive command for PDB

[ywq880611]

Feature or enhancement

Proposal:

Hi Guys!

In the current pdb interactive command list, there is only up and down command for switching the frame, but it's really inflexibility when we meet a very depth stack, we may have to count how many number of stack we would like to up or down

Under such a background, I proposed here to introduce a new command like frame (just like what it did in GDB) to switch the current frame with the frame index came from the bt command.

A case like:

def a():
    breakpoint()
    print("a")

def b():
    a()
    print("b")

def c():
    
    b()
    print("c")

if __name__ == "__main__":
    c()

We could see some workflow like:

> /home/wenqin/work/my-python/script/nested-stack.py(4)a()
-> breakpoint()
(Pdb) bt
#0   /home/wenqin/work/my-python/script/nested-stack.py(17)<module>()
-> c()
#1   /home/wenqin/work/my-python/script/nested-stack.py(13)c()
-> b()
#2   /home/wenqin/work/my-python/script/nested-stack.py(8)b()
-> a()
#3 > /home/wenqin/work/my-python/script/nested-stack.py(4)a()
-> breakpoint()
(Pdb) f 1
> /home/wenqin/work/my-python/script/nested-stack.py(13)c()
-> b()
(Pdb) bt
#0   /home/wenqin/work/my-python/script/nested-stack.py(17)<module>()
-> c()
#1 > /home/wenqin/work/my-python/script/nested-stack.py(13)c()
-> b()
#2   /home/wenqin/work/my-python/script/nested-stack.py(8)b()
-> a()
#3   /home/wenqin/work/my-python/script/nested-stack.py(4)a()
-> breakpoint()

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-126785: introduce frame command for pdb #126786

[gaogaotiantian]

So first of all, this is a dup of #110953.

The reason why we don't have frame command, is not the lack of implementation. If we want to make frame command useful, we need to display frame number next to the frame stack (where command basically). However, this is a breaking change (all the related tests would fail), which made it non-minor.

pdb is a command line tool by itself, but it's also used as a base class by a lot of other 3rd party debuggers, we can't simply change the output of where because that could potentially break other code.

This is why I'm trying to push the config command (#111013) so users can config pdb with .pdbrc. However, that did not go too well.

At this time, I don't believe it's feasible to just add frame support with changes to where command. One way to achieve that is to have a discussion at discuss.python.org and get support from the community, including a few core devs. We can then come up with a plan to support this feature. Otherwise I don't think we can just slip this in.

[ywq880611]

I see... Thank you for your quick response!

I do understand your points about that it may break some test and 3rd party debuggers, but I'm curious about how cpython community tracks 3rd party debuggers, because I didn't see there is test failed in my PR about the 3rd party debuggers, IIUC, if the cpython community thought that some 3rd party debuggers (or some other libs) as critical, then them should be added into the test set and CI/CD process, right? If there is no such a test set, we may get into a endless back compatibility problem... because we even not know what the enemy is, but I digress.

I also saw your PR about configuring the customizable behavior of pdb, I thought it's a very good approach to solve these problems you mentioned, hope everything goes well, thank you for your review and suggestions again!

[gaogaotiantian]

If there is no such a test set, we may get into a endless back compatibility problem

This is the reality when you are working with a programming language with millions of users. We care a lot about backward compatibilities. It's impossible to keep track of all third party apps, but it is a fact that when we change something, there could be apps out there that break. We are trying to be very careful when we change the existing APIs, that's why we have a deprecation process for any API that we change or remove.

Unfortunately, flexibility is not the luxury we have when we deal with a project like CPython. We can't say "Oh I did not see anything break, let's do it". We think all 3rd party libraries/apps out there "important". It's not saying that we will never change anything, it's just we need a really good justification.

That being said, I believe there are 3rd party debuggers in the market that actually support this feature. They also have a much better flexibility to change the interface as they like. Another possibility is to try their debugger and see if it solves your issue.

I will have this in mind and see if I can make any progress on the matter.

[ywq880611]

Thank you for your insights! I will try some other 3rd party debugger later!

[user202729]

Just come across this. To @gaogaotiantian : does the following sound reasonable?

1. We can just have frame command in first then figure out what to do with printing frame number later. The implementation in gh-126785: introduce frame command for pdb #126786 doesn't look like it could cause any backwards compatibility issue, and that implementation is sufficient to select the topmost frame because it also prints out total number of frames is in case of error.
2. What about the following implementation: where -n adds the line numbers. Users can do alias where "where -n %* to enable the behavior by default.

[ywq880611]

Hi @user202729 !

IIUC, you means we dont modify the output for default bt or where command, but modify the output of where -n (in this model, we could print the index of frame), then we could use f command to switch the frame, is my understand right?

@gaogaotiantian , WDYT? If this approach makes sense, I could update my PR to achieve this.