GeezerVison

Hi @iritkatriel , this is a very straighforward feature (implementation wise) and the code change is trivial. It's only about whether we should do it or not. Could you give it a review when you have some time? Thanks!

Hi @iritkatriel , this is a very straighforward feature (implementation wise) and the code change is trivial. It's only about whether we should do it or not. Could you give it a review when you have some time? Thanks!

Sorry only saw this now.

Can this break anything?

Sorry only saw this now.

Can this break anything?

I can't think of any meaningful case that this could break. This change only affects how "cmd" parse commands - basically what characters can be considered as the command. In pdb, we expect users to use space to separate commands and args. All the supported commands only contain letters.

So in real world, this will only make a difference when the user types a string that contains characters other than letters, numbers and underscores, for example, c['a']. In such cases, the user always almost want to evaluate the expression(or execute the statement), but forget that c is a command.

This feature basically changed the behavior when the user types such statements/expressions - it does not report "command invalid" anymore - it runs the statement/expression.

This needs to be documented quite prominently as a new feature because it changes behaviour quite visibly. Someone might be surprised that something now executes code when it was previously a NOP.

This needs to be documented quite prominently as a new feature because it changes behaviour quite visibly. Someone might be surprised that something now executes code when it was previously a NOP.

I think the behavior after this change actually is closer to what the current documentation claims.

Arguments to commands must be separated by whitespace (spaces or tabs)

This defines how pdb should treat commands and arguments, which is not what we are doing now. According to the current docs, if the user inputs c['a'], it should be treated as a "command" because there's no whitespace anywhere. However, the current behavior treats it as command c + argument ['a'], which is against the docs.

I don't think anyone would be surprised if they input c['a'] and pdb evaluates the expression. If anything, this change eliminates a lot of surprises. The user would be pretty surprised if they do c['a'] and pdb complaints that it does not recognize the argument ['a'].

We also claimed in the docs that

Commands that the debugger doesn’t recognize are assumed to be Python statements and are executed in the context of the program being debugged

which is exactly what this change tries to do - c['a'] is not a command the debugger recognizes and should be considered as a Python expression.

Why would the user expect different behavior when they do d['a'] (currently evaluates the expression) and c['a'] (currently reports an error)? That's not intuitive.

I honestly can not think of a single case where the user would feel surprised with this change, even if they are very used to the old pdb.

I'm not disputing the value of the change. But it's a change in behaviour which needs to be documented (a versionchanged entry, a what's new in 3.13 entry).

Maybe someone will be surprised by the 3.12 behaviour, or the change between 3.12 and 3.13. It should be clear from the docs that this is a deliberate change.

I'm not disputing the value of the change. But it's a change in behaviour which needs to be documented (a versionchanged entry, a what's new in 3.13 entry).

Maybe someone will be surprised by the 3.12 behaviour, or the change between 3.12 and 3.13. It should be clear from the docs that this is a deliberate change.

Okay, I'm a bit confused about what to document, as this is more like a "bug fix" to make pdb behave like it claimed.

Maybe

pdb will execute the Python statement even if the first piece of the statement (seperated by spaces) starts with a pdb command.

This is basically what this feature fixes. I'm not sure how to organize the explanation as it's doing what the docs say. Any suggestsions on the matter?

I think something like:

.. versionchanged 3.13

   Expressions whose prefix is a pdb command are now correctly identified and executed.

And something similar in what's new in 3.13.