Feature or enhancement

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

Proposal:

When people are using pdb, they often input an expression to check the evaluation of the expression.

(Pdb) data = 1
(Pdb) data
1
(Pdb)

This would normally work, but it could get complicated when the variable happens to be a command as well. If the variable is a command, there's nothing we can do, but we can deal with it in the following situation:

(Pdb) c.a

Before #103464, this would simply do a continue, which is a horrible experience for users - it's so confusing. After the argument check, it can realize the command "c(ontinue)" comes with an argument ".a" which is weird, and refuse to execute it with a warning to the user. However, the more intuitive result for the input is to print c.a - that's what the user expects.

The problem behind it is how cmd.Cmd parses commands - by default the identchars are the ones that can be used for a variable name, which makes sense, but would parse c.a as command c and argument .a.

For pdb, we'd rather parse this as command c.a - search for it's corresponding do_ method - fail and fallback to default which is run it in Python.

Therefore, we should expand the identchars for Pdb, so we can read this full expression/statement as a command to trigger the default behavior, rather than to use the part that can be a variable name as the command - in no case that works as expected.

This would make inputs like

c.a
c['a']
n()
j=1
r"a"

work.

Linked PRs

• gh-108463: Make expressions/statements work as expected in pdb #108464