Description
Bug report
Bug description:
a = 1
print(a)
breakpoint()
a = 2
print(a)
Works fine with pdb:
❯ python3.14 --version
Python 3.14.0b1
❯ python3.14 1.py
1
> /private/tmp/1.py(3)<module>()
-> breakpoint()
(Pdb)
However, after installing pdbpp 0.11.6 (which has recently been forked and resurrected):
❯ python3.14 1.py
1
Traceback (most recent call last):
File "/private/tmp/1.py", line 3, in <module>
breakpoint()
~~~~~~~~~~^^
File "/Library/Frameworks/Python.framework/Versions/3.14/lib/python3.14/pdb.py", line 2655, in set_trace
pdb.set_trace(sys._getframe().f_back, commands=commands)
~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Pdb.set_trace() got an unexpected keyword argument 'commands'
(Python 3.13 works as expected.)
This is because the commands
argument has been added in 3.14:
https://docs.python.org/3.14/library/pdb.html#pdb.set_trace
And it's likely that pdbpp has subclassed Pdb
and doesn't yet support commands
.
@gaogaotiantian Is this something that pdb or pdbpp should fix?
I've not tested other debuggers.
CPython versions tested on:
3.14
Operating systems tested on:
macOS
Activity
gaogaotiantian commentedon May 12, 2025
I think they already fixed it a few days ago.
This is something pdbpp should fix, because they actually hacked
pdb
sopdb.set_trace
can point to their code, instead of real pdb. If you are monkey patching the standard library, it's your responsibility to sync everything. I believe they did it to make pdbpp a "drop in replacement" - that after installing the package (and probably importing it) you don't need to do anything special to bring it up.However, for a normal derived debugger, they should not rely on
pdb.set_trace
to bring up their debugger, and they should be able to control everything. This new feature itself should not break any code unless they are doing something shady.hugovk commentedon May 13, 2025
Thanks, and I see they've fixed it in bretello/pdbpp#43 👍