Save `pdb` Line History Between Runs

[George-Ogden]

Feature or enhancement

Proposal:

When using pdb, it is possible to use the arrow keys (up/down) to navigate through previous commands. However, commands between runs are not preserved (unlike in the REPL).

I would like commands to be preserved between runs. For me, the most common use case for this is setting a breakpoint in the same place. Currently, I do this with python -m pdb -c "break file.py:line" ....

I am not familiar with how the pdb is implemented, but I have used bdb in depth in the past. I assume that it is possible to do this in a similar way to the REPL history. There is a workaround available here: https://stackoverflow.com/a/35390866/.

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

[picnixz]

cc @gaogaotiantian

[gaogaotiantian]

In an ideal world, pdb should just use pyrepl. It was discussed a while ago but we are waiting for pyrepl to become more stable. I think this requires a separate history file for pdb? I can investigate.

[George-Ogden]

I agree - other features, such as multiline statements and highlighting, would also be great for pdb. That might be a long way off, but adding a separate history could be possible in the nearer term.

[the-osiris]

Is this up for grabs?

I’d like to propose adding optional persistent command history to pdb, so that commands like break file.py:10 can be reused across debugging sessions via arrow-key navigation. The idea is straightforward: when enabled (via an env var like PYTHONPDBHISTORY=1, a hist on command in .pdbrc, or a --history flag), pdb will load history from a small history file on startup and write back to it on exit, using readline where available. This keeps default behavior unchanged, avoids breaking .pdbrc, and provides a lightweight, cross-platform enhancement for frequent pdb users. I’m happy to implement the feature and provide tests if this direction sounds reasonable.

[gaogaotiantian]

@the-osiris, could you circle back in a month or two? I plan to migrate the front-end of pdb to _pyrepl just like the current REPL. If I managed to do that, we wouldn't have this issue because they will share history.

[the-osiris]

Sure @gaogaotiantian, do you need any help in the migration?

[gaogaotiantian]

I think currently I should do it myself. I'm the person that understands how pdb works the most at this moment. I do believe when the first draft is done, there will be plenty of things to do - find corner cases, add extra tests, figure out how the rest of the code should interact with the new repl better. I would love if you can take a look at the newly migrated pdb and help fixing issues then!

[the-osiris]

Sure thing!