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:
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
work.
Linked PRs
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.
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:
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 printc.a- that's what the user expects.The problem behind it is how
cmd.Cmdparses commands - by default theidentcharsare the ones that can be used for a variable name, which makes sense, but would parsec.aas commandcand argument.a.For pdb, we'd rather parse this as command
c.a- search for it's correspondingdo_method - fail and fallback to default which is run it in Python.Therefore, we should expand the
identcharsforPdb, 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
work.
Linked PRs