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)data1(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 acontinue, 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 printc.a - that's what the user expects.

The problem behind it is howcmd.Cmd parses commands - by default theidentchars are the ones that can be used for a variable name, which makes sense, but would parsec.a as commandc and argument.a.

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

Therefore, we should expand theidentchars forPdb, 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.ac['a']n()j=1r"a"

work.

Linked PRs

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