Skip to content

gh-143055: Implementation of PEP 798 #143056

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JelleZijlstra merged 16 commits into from
Jan 31, 2026
Merged

gh-143055: Implementation of PEP 798 #143056

Show file tree
Hide file tree
Changes from 8 commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
0288001
tests for pep798
adqm Nov 7, 2025
a7ea132
initial implementation of pep798 basics
adqm Nov 7, 2025
c23496e
update error messages
adqm Nov 7, 2025
49405ac
improve error reporting for invalid starred expressions
adqm Nov 10, 2025
26841f9
fix for affected test case in test_encodings
adqm Dec 21, 2025
3ebe2f6
add news blurb
adqm Dec 21, 2025
0713bbc
first pass at adding documentation for comprehension unpacking
adqm Jun 24, 2025
0393552
code formatting
adqm Dec 21, 2025
fa16f82
Apply suggestions from code review
adqm Dec 22, 2025
81e86b3
rearrange dict comprehension reference into a bulleted list
adqm Dec 22, 2025
74df6b9
0 -> zero
adqm Dec 23, 2025
23538a8
use `.. versionchanged:: next` instead of `3.15`
adqm Dec 23, 2025
fcf129f
docs: fix generator_expression grammar rule
adqm Dec 24, 2025
acaf3b1
remove redundant grammar rule
adqm Jan 29, 2026
b5ae690
add "what's new" blurb
adqm Jan 30, 2026
7c16250
Merge branch 'main' into pep798
JelleZijlstra Jan 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 29 additions & 12 deletions Doc/reference/expressions.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -266,17 +266,18 @@ called "displays", each of them in two flavors:
Common syntax elements for comprehensions are:

.. productionlist:: python-grammar
comprehension: `assignment_expression` `comp_for`
comprehension: `flexible_expression` `comp_for`
comp_for: ["async"] "for" `target_list` "in" `or_test` [`comp_iter`]
comp_iter: `comp_for` | `comp_if`
comp_if: "if" `or_test` [`comp_iter`]

The comprehension consists of a single expression followed by at least one
:keyword:`!for` clause and zero or more :keyword:`!for` or :keyword:`!if` clauses.
In this case, the elements of the new container are those that would be produced
by considering each of the :keyword:`!for` or :keyword:`!if` clauses a block,
nesting from left to right, and evaluating the expression to produce an element
each time the innermost block is reached.
:keyword:`!for` clause and zero or more :keyword:`!for` or :keyword:`!if`
clauses. In this case, the elements of the new container are those that would
be produced by considering each of the :keyword:`!for` or :keyword:`!if`
clauses a block, nesting from left to right, and evaluating the expression to
produce an element each time the innermost block is reached. If the expression
is starred, the result will instead be unpacked to produce 0 or more elements.
Comment thread
ZeroIntensity marked this conversation as resolved.
Outdated

However, aside from the iterable expression in the leftmost :keyword:`!for` clause,
the comprehension is executed in a separate implicitly nested scope. This ensures
Expand Down Expand Up @@ -321,6 +322,9 @@ See also :pep:`530`.
asynchronous functions. Outer comprehensions implicitly become
asynchronous.

.. versionchanged:: 3.15
Comment thread
ZeroIntensity marked this conversation as resolved.
Outdated
Unpacking with the ``*`` operator is now allowed in the expression.


.. _lists:

Expand Down Expand Up @@ -396,8 +400,8 @@ enclosed in curly braces:
.. productionlist:: python-grammar
dict_display: "{" [`dict_item_list` | `dict_comprehension`] "}"
dict_item_list: `dict_item` ("," `dict_item`)* [","]
dict_comprehension: `dict_item` `comp_for`
dict_item: `expression` ":" `expression` | "**" `or_expr`
dict_comprehension: `expression` ":" `expression` `comp_for`

A dictionary display yields a new dictionary object.

Expand All @@ -419,10 +423,21 @@ earlier dict items and earlier dictionary unpackings.
.. versionadded:: 3.5
Unpacking into dictionary displays, originally proposed by :pep:`448`.

A dict comprehension, in contrast to list and set comprehensions, needs two
expressions separated with a colon followed by the usual "for" and "if" clauses.
When the comprehension is run, the resulting key and value elements are inserted
in the new dictionary in the order they are produced.
A dict comprehension may take one of two forms:

The first form uses two expressions separated with a colon followed by the
Comment thread
JelleZijlstra marked this conversation as resolved.
Outdated
usual "for" and "if" clauses. When the comprehension is run, the resulting key
and value elements are inserted in the new dictionary in the order they are
produced.

The second form uses a single expression prefixed by the ``**`` dictionary
unpacking operator followed by the usual "for" and "if" clauses. When the
comprehension is run, the expression is evaluated and then unpacked, inserting
0 or more key/value pairs into the new dictionary.
Comment thread
adqm marked this conversation as resolved.
Outdated

Both forms of dictionary comprehension retain the property that if the same key
is specified multiple times, the associated value in the resulting dictionary
will be the last one specified.

.. index:: pair: immutable; object
hashable
Expand All @@ -439,6 +454,8 @@ prevails.
the key. Starting with 3.8, the key is evaluated before the value, as
proposed by :pep:`572`.

.. versionchanged:: 3.15
Unpacking with the ``**`` operator is now allowed in dictionary comprehensions.

.. _genexpr:

Expand All @@ -453,7 +470,7 @@ Generator expressions
A generator expression is a compact generator notation in parentheses:

.. productionlist:: python-grammar
generator_expression: "(" `expression` `comp_for` ")"
generator_expression: "(" starred_expression `comp_for` ")"

A generator expression yields a new generator object. Its syntax is the same as
for comprehensions, except that it is enclosed in parentheses instead of
Expand Down
19 changes: 19 additions & 0 deletions Doc/tutorial/classes.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -929,6 +929,25 @@ Examples::
>>> list(data[i] for i in range(len(data)-1, -1, -1))
['f', 'l', 'o', 'g']

>>> x = [[1,2,3], [], [4, 5]]
>>> g = (*i for i in x)
>>> list(g)
[1, 2, 3, 4, 5]

In most cases, generator expressions must be wrapped in parentheses. As a
special case, however, when provided as the sole argument to a function (as in
the examples involving ``sum``, ``set``, ``max``, and ``list`` above), the
generator expression does not need to be wrapped in an additional set of
parentheses. That is to say, the following two pieces of code are semantically
equivalent::

>>> f(x for x in y)
>>> f((x for x in y))

as are the following::

>>> f(*x for x in y)
>>> f((*x for x in y))


.. rubric:: Footnotes
Expand Down
64 changes: 62 additions & 2 deletions Doc/tutorial/datastructures.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -333,6 +333,47 @@ The :func:`zip` function would do a great job for this use case::

See :ref:`tut-unpacking-arguments` for details on the asterisk in this line.

Unpacking in Lists and List Comprehensions
------------------------------------------

The section on :ref:`tut-unpacking-arguments` describes the use of ``*`` to
"unpack" the elements of an iterable object, providing each one seperately as
an argument to a function. Unpacking can also be used in other contexts, for
example, when creating lists. When specifying elements of a list, prefixing an
expression by a ``*`` will unpack the result of that expression, adding each of
its elements to the list we're creating::

>>> x = [1, 2, 3]
>>> [0, *x, 4, 5, 6]
[0, 1, 2, 3, 4, 5, 6]

This only works if the expression following the ``*`` evaluates to an iterable
object; trying to unpack a non-iterable object will raise an exception::

>>> x = 1
>>> [0, *x, 2, 3, 4]
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
[0, *x, 2, 3, 4]
TypeError: Value after * must be an iterable, not int

Unpacking can also be used in list comprehensions, as a way to build a new list
representing the concatenation of an arbitrary number of iterables::

>>> x = [[1, 2, 3], [4, 5, 6], [], [7], [8, 9]]
>>> [*element for element in x]
[1, 2, 3, 4, 5, 6, 7, 8, 9]

Note that the effect is that each element from ``x`` is unpacked. This works
for arbitrary iterable objects, not just lists::

>>> x = [[1, 2, 3], 'cat', {'spam': 'eggs'}]
>>> [*element for element in x]
[1, 2, 3, 'c', 'a', 't', 'spam']

But if the objects in ``x`` are not iterable, this expression would again raise
an exception.

.. _tut-del:

The :keyword:`!del` statement
Expand Down Expand Up @@ -394,7 +435,10 @@ A tuple consists of a number of values separated by commas, for instance::
>>> v = ([1, 2, 3], [3, 2, 1])
>>> v
([1, 2, 3], [3, 2, 1])

>>> # they support unpacking just like lists:
>>> x = [1,2,3]
Comment thread
adqm marked this conversation as resolved.
Outdated
>>> 0, *x, 4
(0, 1, 2, 3, 4)

As you see, on output tuples are always enclosed in parentheses, so that nested
tuples are interpreted correctly; they may be input with or without surrounding
Expand Down Expand Up @@ -480,12 +524,16 @@ Here is a brief demonstration::
{'r', 'd', 'b', 'm', 'z', 'l'}

Similarly to :ref:`list comprehensions <tut-listcomps>`, set comprehensions
are also supported::
are also supported, including comprehensions with unpacking::

>>> a = {x for x in 'abracadabra' if x not in 'abc'}
>>> a
{'r', 'd'}

>>> fruits = [{'apple', 'avocado', 'apricot'}, {'banana', 'blueberry'}]
>>> {*fruit for fruit in fruits}
{'blueberry', 'banana', 'avocado', 'apple', 'apricot'}


.. _tut-dictionaries:

Expand Down Expand Up @@ -563,6 +611,18 @@ arbitrary key and value expressions::
>>> {x: x**2 for x in (2, 4, 6)}
{2: 4, 4: 16, 6: 36}

And dictionary unpacking (via ``**``) can be used to merge multiple
dictionaries::

>>> odds = {i: i**2 for i in (1, 3, 5)}
>>> evens = {i: i**2 for i in (2, 4, 6)}
>>> {**odds, **evens}
{1: 1, 3: 9, 5: 25, 2: 4, 4: 16, 6: 36}

>>> all_values = [odds, evens, {0: 0}]
>>> {**i for i in all_values}
{1: 1, 3: 9, 5: 25, 2: 4, 4: 16, 6: 36, 0: 0}

When the keys are simple strings, it is sometimes easier to specify pairs using
keyword arguments::

Expand Down
67 changes: 48 additions & 19 deletions Grammar/python.gram
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -709,12 +709,17 @@ expressions[expr_ty]:
| expression

expression[expr_ty] (memo):
| invalid_if_expression
| invalid_expression
| invalid_legacy_expression
| a=disjunction 'if' b=disjunction 'else' c=expression { _PyAST_IfExp(b, a, c, EXTRA) }
| if_expression
| disjunction
| lambdef

if_expression[expr_ty]:
| a=disjunction 'if' b=disjunction 'else' c=expression { _PyAST_IfExp(b, a, c, EXTRA) }
| invalid_if_expression
Copy link
Copy Markdown
Member

@lysnikolaou lysnikolaou Jan 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure this alternative is never reached, since, in the second pass, it's encountered in expression before we get to if_expression and only in invalid rules otherwise that will overwrite the error either way.

Copy link
Copy Markdown
Contributor Author

@adqm adqm Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking a look! Yep, I think you're right that we can't reach invalid_if_expression here, good catch. I'll push that change today (along with a what's new entry).


yield_expr[expr_ty]:
| 'yield' 'from' a=expression { _PyAST_YieldFrom(a, EXTRA) }
| 'yield' a=[star_expressions] { _PyAST_Yield(a, EXTRA) }
Expand All @@ -731,10 +736,16 @@ star_expression[expr_ty] (memo):

star_named_expressions[asdl_expr_seq*]: a[asdl_expr_seq*]=','.star_named_expression+ [','] { a }

star_named_expressions_sequence[asdl_expr_seq*]: a[asdl_expr_seq*]=','.star_named_expression_sequence+ [','] { a }

star_named_expression[expr_ty]:
| '*' a=bitwise_or { _PyAST_Starred(a, Load, EXTRA) }
| named_expression

star_named_expression_sequence[expr_ty]:
| invalid_starred_expression_unpacking_sequence
| star_named_expression

assignment_expression[expr_ty]:
| a=NAME ':=' ~ b=expression {
CHECK_VERSION(expr_ty, 8, "Assignment expressions are",
Expand Down Expand Up @@ -882,9 +893,9 @@ atom[expr_ty]:
| 'None' { _PyAST_Constant(Py_None, NULL, EXTRA) }
| &(STRING|FSTRING_START|TSTRING_START) strings
| NUMBER
| &'(' (tuple | group | genexp)
| &'[' (list | listcomp)
| &'{' (dict | set | dictcomp | setcomp)
| &'(' ( genexp | tuple | group)
Comment thread
adqm marked this conversation as resolved.
Outdated
| &'[' (listcomp | list)
| &'{' (dictcomp | setcomp | dict | set)
Comment on lines +895 to +897
Copy link
Copy Markdown
Member

@lysnikolaou lysnikolaou Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing the order here is probably only about error messages, right? If so, have you checked whether this affects parsing performance at all? To be clear, I'm okay to sacrifice a bit of performance for better error messages.

Copy link
Copy Markdown
Contributor Author

@adqm adqm Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, the reordering here was purely for error reporting. I hadn't done any performance testing before, but I did a quick, unscientific test this morning, doing some quick timings on ast.parse for a few things.

As might be expected, compared to the place I branched from, it looks like this branch is, in general, a little bit faster on comprehensions and a little bit slower on literal lists. It's a little hard to say how this works out on the whole, but the time for parsing the full standard library was always within ±2% every time I ran it. I can look more thoroughly if we're concerned about this, but this little test at least suggests that things haven't blown up on average.

Sample results:

TestReasonThis BranchMerge baseChange
[] (1e5 times)empty list0.58380.5539~5% slower
[x, y, z, a, b, c] (1e5 times)well-formed list1.40511.3827~2% slower
[1, 2, 3, 4, 5, 6 (1e5 times)broken list1.17501.1413~3% slower
[x for x in y if z and a] (1e5 times)well-formed comprehension1.16421.2393~6% faster
[x for x in (1e5 times)broken comprehension0.65680.7014~6% faster
[**x for x in y] (1e5 times)broken comprehension unpacking (new specific error message)1.26751.0519~20% slower
[x if x else y] (1e5 times)good ifexp1.01630.9890~3% slower
[*x if x else y] (1e5 times)broken ifexp (new specific error message)1.32991.7870~26% faster
full stdlib (5 times)26.164126.2642~equal

| '...' { _PyAST_Constant(Py_Ellipsis, NULL, EXTRA) }

group[expr_ty]:
Expand Down Expand Up @@ -998,13 +1009,13 @@ strings[expr_ty] (memo):
| a[asdl_expr_seq*]=tstring+ { _PyPegen_concatenate_tstrings(p, a, EXTRA) }

list[expr_ty]:
| '[' a=[star_named_expressions] ']' { _PyAST_List(a, Load, EXTRA) }
| '[' a=[star_named_expressions_sequence] ']' { _PyAST_List(a, Load, EXTRA) }

tuple[expr_ty]:
| '(' a=[y=star_named_expression ',' z=[star_named_expressions] { _PyPegen_seq_insert_in_front(p, y, z) } ] ')' {
| '(' a=[y=star_named_expression_sequence ',' z=[star_named_expressions_sequence] { _PyPegen_seq_insert_in_front(p, y, z) } ] ')' {
_PyAST_Tuple(a, Load, EXTRA) }

set[expr_ty]: '{' a=star_named_expressions '}' { _PyAST_Set(a, EXTRA) }
set[expr_ty]: '{' a=star_named_expressions_sequence '}' { _PyAST_Set(a, EXTRA) }

# Dicts
# -----
Expand Down Expand Up @@ -1040,20 +1051,20 @@ for_if_clause[comprehension_ty]:
| invalid_for_target

listcomp[expr_ty]:
| '[' a=named_expression b=for_if_clauses ']' { _PyAST_ListComp(a, b, EXTRA) }
| '[' a=star_named_expression b=for_if_clauses ']' { _PyAST_ListComp(a, b, EXTRA) }
| invalid_comprehension

setcomp[expr_ty]:
| '{' a=named_expression b=for_if_clauses '}' { _PyAST_SetComp(a, b, EXTRA) }
| '{' a=star_named_expression b=for_if_clauses '}' { _PyAST_SetComp(a, b, EXTRA) }
| invalid_comprehension

genexp[expr_ty]:
| '(' a=( assignment_expression | expression !':=') b=for_if_clauses ')' { _PyAST_GeneratorExp(a, b, EXTRA) }
| '(' a=( assignment_expression | expression !':=' | starred_expression ) b=for_if_clauses ')' { _PyAST_GeneratorExp(a, b, EXTRA) }
| invalid_comprehension

dictcomp[expr_ty]:
| '{' a=kvpair b=for_if_clauses '}' { _PyAST_DictComp(a->key, a->value, b, EXTRA) }
| invalid_dict_comprehension
| '{' '**' a=expression b=for_if_clauses '}' { _PyAST_DictComp(a, NULL, b, EXTRA) }

# FUNCTION CALL ARGUMENTS
# =======================
Expand Down Expand Up @@ -1262,6 +1273,12 @@ invalid_expression:
| a='lambda' [lambda_params] b=':' &TSTRING_MIDDLE {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "t-string: lambda expressions are not allowed without parentheses") }

invalid_if_expression:
| disjunction 'if' b=disjunction 'else' a='*' {
RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "cannot unpack only part of a conditional expression") }
| disjunction 'if' b=disjunction 'else' a='**' {
RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "cannot use dict unpacking on only part of a conditional expression") }

invalid_named_expression(memo):
| a=expression ':=' expression {
RAISE_SYNTAX_ERROR_KNOWN_LOCATION(
Expand Down Expand Up @@ -1326,16 +1343,15 @@ invalid_assert_stmt:
invalid_block:
| NEWLINE !INDENT { RAISE_INDENTATION_ERROR("expected an indented block") }
invalid_comprehension:
| ('[' | '(' | '{') a=starred_expression for_if_clauses {
RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "iterable unpacking cannot be used in comprehension") }
| '[' a='**' b=expression for_if_clauses {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "cannot use dict unpacking in list comprehension") }
Comment thread
JelleZijlstra marked this conversation as resolved.
| '(' a='**' b=expression for_if_clauses {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "cannot use dict unpacking in generator expression") }
| ('[' | '{') a=star_named_expression ',' b=star_named_expressions for_if_clauses {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, PyPegen_last_item(b, expr_ty),
"did you forget parentheses around the comprehension target?") }
| ('[' | '{') a=star_named_expression b=',' for_if_clauses {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "did you forget parentheses around the comprehension target?") }
invalid_dict_comprehension:
| '{' a='**' bitwise_or for_if_clauses '}' {
RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "dict unpacking cannot be used in dict comprehension") }
invalid_parameters:
| a="/" ',' {
RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "at least one parameter must precede /") }
Expand Down Expand Up @@ -1530,19 +1546,32 @@ invalid_class_def_raw:
RAISE_INDENTATION_ERROR("expected an indented block after class definition on line %d", a->lineno) }

invalid_double_starred_kvpairs:
| ','.double_starred_kvpair+ ',' invalid_kvpair
| expression ':' a='*' bitwise_or { RAISE_SYNTAX_ERROR_STARTING_FROM(a, "cannot use a starred expression in a dictionary value") }
| invalid_kvpair_unpacking [',']
| ','.double_starred_kvpair+ ',' (invalid_kvpair | invalid_kvpair_unpacking)
| expression a=':' &('}'|',') { RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "expression expected after dictionary key and ':'") }
invalid_kvpair_unpacking:
| a='**' b=if_expression {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid double starred expression. Did you forget to wrap the conditional expression in parentheses?") }
| a='*' b=bitwise_or ':' expression { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "cannot use a starred expression in a dictionary key") }
| a='**' b=bitwise_or ':' expression { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "cannot use dict unpacking in a dictionary key") }
| expression ':' a='*' b=bitwise_or { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "cannot use a starred expression in a dictionary value") }
| expression ':' a='**' b=bitwise_or { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "cannot use dict unpacking in a dictionary value") }
invalid_kvpair:
| a=expression !(':') {
RAISE_ERROR_KNOWN_LOCATION(p, PyExc_SyntaxError, a->lineno, a->end_col_offset - 1, a->end_lineno, -1, "':' expected after dictionary key") }
| expression ':' a='*' bitwise_or { RAISE_SYNTAX_ERROR_STARTING_FROM(a, "cannot use a starred expression in a dictionary value") }
| expression ':' a='**' bitwise_or { RAISE_SYNTAX_ERROR_STARTING_FROM(a, "cannot use dict unpacking in a dictionary value") }
| expression a=':' &('}'|',') {RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "expression expected after dictionary key and ':'") }
invalid_starred_expression_unpacking:
| a='*' b=if_expression {
RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid starred expression. Did you forget to wrap the conditional expression in parentheses?") }
| a='*' expression '=' b=expression { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "cannot assign to iterable argument unpacking") }
invalid_starred_expression_unpacking_sequence:
| a='**' bitwise_or {
RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "cannot use dict unpacking here") }
| invalid_starred_expression_unpacking
invalid_starred_expression:
| '*' { RAISE_SYNTAX_ERROR("Invalid star expression") }

invalid_fstring_replacement_field:
| '{' a='=' { RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "f-string: valid expression required before '='") }
| '{' a='!' { RAISE_SYNTAX_ERROR_KNOWN_LOCATION(a, "f-string: valid expression required before '!'") }
Expand Down
4 changes: 2 additions & 2 deletions Lib/test/test_exceptions.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -337,7 +337,6 @@ def baz():
check('x=1\nfrom __future__ import division', 2, 1)
check('foo(1=2)', 1, 5)
check('def f():\n x, y: int', 2, 3)
check('[*x for x in xs]', 1, 2)
check('foo(x for x in range(10), 100)', 1, 5)
check('for 1 in []: pass', 1, 5)
check('(yield i) = 2', 1, 2)
Expand Down Expand Up @@ -2433,7 +2432,8 @@ def test_encodings(self):
)
err = run_script(source.encode('cp437'))
self.assertEqual(err[-3], ' "¢¢¢¢¢¢" + f(4, x for x in range(1))')
self.assertEqual(err[-2], ' ^^^')
self.assertEqual(err[-2], ' ^^^^^^^^^^^^^^^^^^^')
self.assertEqual(err[-1], 'SyntaxError: Generator expression must be parenthesized')

# Check backwards tokenizer errors
source = '# -*- coding: ascii -*-\n\n(\n'
Expand Down
Loading
Loading