Friendlier syntax for Python debugger: Distinguishing between pdb commands and Python statements

Ideas
1

Currently, the Python debugger (pdb) has a number of commands that are easily conflated with (prefixes of) Python statements. When a user intends the latter, the former get accidentally triggered instead, resulting in an annoying user experience.

For illustration, suppose the following are intended as Python statements. Instead, and perhaps surprisingly, they trigger unrelated pdb commands:

(Pdb) list(generator) # wrong!
(Pdb) next(iterator)  # wrong!
(Pdb) break # wrong!
(Pdb) continue # wrong!
(Pdb) args.path # wrong!
(Pdb) run(example) # wrong!
(Pdb) step += 1 # wrong!
(Pdb) a = 1 # wrong!
(Pdb) b = 2 # wrong!
(Pdb) c = 3 # wrong!
(Pdb) p = 0.5 # wrong!
(Pdb) j = 10 # wrong!
(Pdb) n = 100 # wrong!

To disambiguate legitimate Python statements from pdb commands, they must be prefixed with !.

In practice, since it is

  1. Difficult to remember exactly which identifiers are (prefixes of) pdb commands.
  2. Cumbersome to have to repeatedly switch between using or not using !.

I usually end up prepending all entries intended as Python statements with !. This is annoying, and feels backward from a UX perspective.

IMO, it should be the other way around: It should be pdb commands that are prefixed with !. It is those commands that are “special”, not the opposite.

This also removes the arbitrary choice of using or not using !, resulting in a more uniform interface: If an entry is prefixed by !, it is a pdb command. Otherwise, it is a Python statement. Simple as that.

Indeed, ! is used for “bang magics” and other “meta-commands” in Jupyter Notebook, IPython, and other such settings, so there is precedent for this approach.

Do others agree?

3 Likes
2

Add help(some_function) to that list…

I wish the input parser could notice the ( after a command and from it infer that you want the function rather than the command.

Despite the slightly murky namespace munging, I do like the convenience of just typing u/d/b/c. I never have variable/command name conflicts because I don’t use single letter variable names.

1 Like
3

I don’t really see a problem here.

You can have the opposite problem occur. Variables in current scope which are valid pdb commands like c, n, s.

If you want to do a bunch of inspections you type inspect which puts you into a different session where all debugger commands are ignored

3 Likes
4

I don’t understand your point or how it undermines the OP. Please explain.

That’s not what I want to do.

5

Apologies I mistyped.

For my understanding if you are in pdb and type list(generator) it doesn’t work because list is a pdb commands correct? That’s the issue?

You can type interact while in pdb and it drops you into a different session where pdb commands do not register so your list(generator) will work.

Now the only caveat with this, is that any changes you do to the namespace don’t persist because you get a copy of global and local namespace.

6

Most of the issues you mentioned are already fixed in 3.13. I don’t believe we will enforce a ! prefix for all pdb commands because those are more commonly used in a debugger. I don’t believe gdb or lldb does that either.

I do think the ambiguity resolving is pretty bad in old pdb and that’s why I fixed a lot of them.

6 Likes