Can pudb set breakpoints without inserting "pu.db" in the code? It makes the code dirty

[sisrfeng]

ipdb can use command like: b my.py:112

[asmeurer]

Yes, you can use m to navigate to the module and insert it using b. Or you can add them in the breakpoints config file (I guess we should add documentation on how to do this).

[mvanderkamp]

shameless self-plug: if you use vim, vim-pudb-and-jam offers a way to set these breakpoints from your editor. (The name is because I forked vim-pudb when my PR started to go stale and added some "jammy" features :grin:)

[deliciouslytyped]

It would be nice if breakpoints could be specified on the CLI or an ENV var, the same goes for anything else that exists in the config. This can be helpful if the debug target is in an immutable environment.

Furthermore, it may not always be easy to navigate to the module due to import shenanigans, until you're in an appropriate part of the code, so it would be good if breakpoints could be set on a filepath or delayed until the module is loaded or something.

Edit: A trick you can do is, if you can pause the program before it exits, the modules will now show up in the module list. Then you can add your breakpoint, which will end up in the persistent breakpoint list. Then if you restart your program, it will have the breakpoint.

[inducer]

I'd be happy to consider PRs along these lines.

[asmeurer]

Is there an existing syntax we can use for setting breakpoints on the command line? I didn't see anything for pdb.

Also, if you set a breakpoint in this way, it's important that you start pudb in some way, either by running python -m pudb or running import pudb; pudb.set_trace() somewhere. Otherwise the breakpoints won't actually trigger. This is something that we should make sure to document.

[deliciouslytyped]

I don't know if there is any standard python syntax, if there isn't, it might be good to check if there is one for gdb. Maybe it's also worth checking if there's any issues filed for pdb?

[deliciouslytyped]

I'm not saying it should be done this way, just that this is the precedent I could find offhand; https://stackoverflow.com/a/33808301 shows an approach for pdb where commands can be placed in a .pdbrc, or from some version of python -c can be passed to run arbitrary commands.

https://docs.python.org/3/library/pdb.html states:

b(reak) [([filename:]lineno | function) [, condition]]

    With a lineno argument, set a break there in the current file. With a function argument, set a break at the first executable statement within that function. The line number may be prefixed with a filename and a colon, to specify a breakpoint in another file (probably one that hasn’t been loaded yet). The file is searched on sys.path. Note that each breakpoint is assigned a number to which all the other breakpoint commands refer.

    If a second argument is present, it is an expression which must evaluate to true before the breakpoint is honored.

    Without argument, list all breaks, including for each breakpoint, the number of times that breakpoint has been hit, the current ignore count, and the associated condition if any.

[mvanderkamp]

that sounds an awful lot like the breakpoint file that already exists. Perhaps just exposing that more clearly would be sufficient, or allowing users to specify exactly which breakpoint file to use.

[Freed-Wu]

Can pudb support any breakpoint config file like .pdbrc for pdb or .gdbinit for gdb? I test and found pudb cannot support .pdbrc.

I found ~/.config/pudb/saved-breakpoints-3.9:

b /home/wzy/.pyenv/versions/3.9.13/lib/python3.9/site-packages/ptpython/completer.py:556

Is it a file like pdbrc?