gh-103068: Check condition expression of breakpoints for pdb

[gaogaotiantian]

If the condition expression is not even valid, we should ignore the command and warn the users.

As this is a similar check as display, I made some modifications for display command so they are using the same logic. This also freed _getval_except to do what it used to do - provide the string regardless of the exception. Also, self.error is used for display command when it failed because that's what other(most of?) commands do and it will make the most of sense to users.

walrus operator is used but this will merge back to 3.10 at most, so all the versions affected should support it.

• Issue: pdb's breakpoint should check if condition is a valid expression #103068

[artemmukhin]

Since we have two separate error types for display now

• ** raised <...> **
• *** Unable to display <...>

I think it's worth covering ** raised <...> ** cases in the tests as well, for instance:

(Pdb) display undefined
display undefined: ** raised NameError: name 'undefined' is not defined **

[artemmukhin]

Also, I noticed that break behaviour is different: pdb conservatively stops on the breakpoint ignoring the runtime errors. I think it's worth covering in the tests as well

[ambv]

Do you have a suggestion for a test for the break behavior?

[artemmukhin]

Sure, here is a patch:

--- a/Lib/test/test_pdb.py
+++ b/Lib/test/test_pdb.py
@@ -266,6 +266,8 @@ def test_pdb_breakpoint_commands():
     ...     'commands 10',  # out of range
     ...     'commands a',   # display help
     ...     'commands 4',   # already deleted
+    ...     'break 6, undefined', # condition causing `NameError` during evaluation
+    ...     'continue', # will stop, ignoring runtime error
     ...     'continue',
     ... ]):
     ...    test_function()
@@ -337,8 +339,13 @@ def test_pdb_breakpoint_commands():
             end
     (Pdb) commands 4
     *** cannot set commands: Breakpoint 4 already deleted
+    (Pdb) break 6, undefined
+    Breakpoint 5 at <doctest test.test_pdb.test_pdb_breakpoint_commands[0]>:6
     (Pdb) continue
     3
+    > <doctest test.test_pdb.test_pdb_breakpoint_commands[0]>(6)test_function()
+    -> print(4)
+    (Pdb) continue
     4
     """

[ambv]

I noticed that the pattern to call traceback.format_exception_only(exc)[-1].strip() is repeated a few times so I made this into a method. Moreover, even though this was sometimes using the two-argument form and sometimes the single-argument form, since Python 3.10 the two are equivalent so it makes no difference. Therefore, I just added the single-argument form.

I changed the name of the check method, and added a test for an otherwise failing display, per Artem's suggestions.

[gaogaotiantian]

LGTM

[gaogaotiantian]

Side note: do we use type hints in standard library? Most of the builtin libraries do not have type hints(at least inline). Just saw you added a function with one and it just stands out.

[AlexWaygood]

Side note: do we use type hints in standard library? Most of the builtin libraries do not have type hints(at least inline). Just saw you added a function with one and it just stands out.

Most stdlib modules don't have type hints, but there isn't a hard-and-fast rule against including them for new code, if it makes the purpose/signature of the function easier to understand. You'll find lots of type hints in tomllib and importlib.metadata, and a few in typing.py itself and parts of asyncio.

[ambv]

There used to be a hard rule against type hints in the past but it's been eroding since. Thanks to Jason's precedent in pdb I felt like adding new type hints wasn't out of place.