When an exception is created in a nested call to PyObject_GetAttr, any
external calls will override the context information of the
AttributeError that we have already placed in the most internal call.
This will cause the suggestions we create to nor work properly as the
attribute name and object that we will be using are the incorrect ones.
To avoid this, we need to check first if these attributes are already
set and bail out if that's the case..
(cherry picked from commit 3b3be05a16)
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
The test tested that explicitly deleting the local variable bound to the exception
did not cause problems, but it did not test what it actually claimed to test, i.e.
that the variable is deleted automatically.
(cherry picked from commit 82c53229e1)
Co-authored-by: Yellow Dusk <yellow.dusk1590@fastmail.com>
* bpo-46339: Fix crash in the parser when computing error text for multi-line f-strings (GH-30529)
Automerge-Triggered-By: GH:pablogsal
(cherry picked from commit cedec19be8)
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
* Fix interactive mode
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
(cherry picked from commit 4325a766f5)
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
(cherry picked from commit 59435eea08)
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
There are two errors that this commit fixes:
* The parser was not correctly computing the offset and the string
source for E_LINECONT errors due to the incorrect usage of strtok().
* The parser was not correctly unwinding the call stack when a tokenizer
exception happened in rules involving optionals ('?', [...]) as we
always make them return valid results by using the comma operator. We
need to check first if we don't have an error before continuing..
(cherry picked from commit a106343f63)
Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
Fix typos in the Lib directory as identified by codespell.
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>.
(cherry picked from commit 745c9d9dfc)
Co-authored-by: Christian Clauss <cclauss@me.com>
Fix test_name_error_suggestions_do_not_trigger_for_too_many_locals()
of test_exceptions if a directory name contains "a1" (like
"Python-3.11.0a1"): use a stricter regular expression.
(cherry picked from commit 4e605666b0)
Co-authored-by: Victor Stinner <vstinner@python.org>
This is part of an investigation of a non-deterministic reference leak. While we're looking for the root cause, this is included temporarily so that CI doesn't fail on this particular issue. This enables it to find other regressions in the meantime, which would otherwise be shadowed by our known issue.
(cherry picked from commit 7bf28cbb4b)
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
To improve the user experience understanding what part of the error messages associated with SyntaxErrors is wrong, we can highlight the whole error range and not only place the caret at the first character. In this way:
>>> foo(x, z for z in range(10), t, w)
File "<stdin>", line 1
foo(x, z for z in range(10), t, w)
^
SyntaxError: Generator expression must be parenthesized
becomes
>>> foo(x, z for z in range(10), t, w)
File "<stdin>", line 1
foo(x, z for z in range(10), t, w)
^^^^^^^^^^^^^^^^^^^^
SyntaxError: Generator expression must be parenthesized
When printing NameError raised by the interpreter, PyErr_Display
will offer suggestions of simmilar variable names in the function that the exception
was raised from:
>>> schwarzschild_black_hole = None
>>> schwarschild_black_hole
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'schwarschild_black_hole' is not defined. Did you mean: schwarzschild_black_hole?
Matthieu Dartiailh