Syntax

The necessary grammatical changes are allowing the expression in list/set comprehensions and generator expressions to be preceded by a *, and allowing an alternative form of dictionary comprehension in which a double-starred expression can be used in place of a key: value pair.

This can be accomplished by updating the listcomp and setcomp rules to use star_named_expression instead of named_expression:

listcomp[expr_ty]:
    | '[' a=star_named_expression b=for_if_clauses ']'

setcomp[expr_ty]:
    | '{' a=star_named_expression b=for_if_clauses '}'

The rule for genexp would similarly need to be modified to allow a starred_expression:

genexp[expr_ty]:
    | '(' a=(assignment_expression | expression !':=' | starred_expression) b=for_if_clauses ')'

The rule for dictionary comprehensions would need to be adjusted as well, to allow for this new form:

dictcomp[expr_ty]:
    | '{' a=double_starred_kvpair b=for_if_clauses '}'

No change should be made to the way that argument unpacking is handled in function calls, i.e., the general rule that generator expressions provided as the sole argument to functions do not require additional redundant parentheses should be retained. Note that this implies that, for example, f(*x for x in it) is equivalent to f((*x for x in it)) (see Starred Generators as Function Arguments for more discussion).

* and ** should only be allowed at the top-most level of the expression in the comprehension (see Further Generalizing Unpacking Operators for more discussion).

Semantics: List/Set/Dict Comprehensions

The meaning of a starred expression in a list comprehension [*expr for x in it] is to treat each expression as an iterable, and concatenate them, in the same way as if they were explicitly listed via [*expr1, *expr2, ...]. Similarly, {*expr for x in it} forms a set union, as if the expressions were explicitly listed via {*expr1, *expr2, ...}; and {**expr for x in it} combines dictionaries, as if the expressions were explicitly listed via {**expr1, **expr2, ...}. These operations should retain all of the equivalent semantics for combining collections in this way (including, for example, later values replacing earlier ones in the case of a duplicated key when combining dictionaries).

Said another way, the objects created by the following comprehensions:

new_list = [*expr for x in its]
new_set = {*expr for x in its}
new_dict = {**expr for d in dicts}

should be equivalent to the objects created by the following pieces of code, respectively:

new_list = []
for x in its:
    new_list.extend(expr)

new_set = set()
for x in its:
    new_set.update(expr)

new_dict = {}
for x in dicts:
    new_dict.update(expr)

Semantics: Generator Expressions

A generator expression (*expr for x in it) forms a generator producing values from the concatenation of the iterables given by the expressions. Specifically, the behavior is defined to be equivalent to the following generator:

def generator():
    for x in it:
        yield from expr

Since yield from is not allowed inside of async generators, the equivalent for (*expr async for x in ait()), is more like the following (though of course this new form should not define or reference the looping variable i):

async def generator():
    async for x in ait():
        for i in expr:
            yield i

def generator():
    for i in (0, 2, 4):
        yield from (y := [i, i+1])

>>> g = (*(y := [i, i+1]) for i in (0, 2, 4))
>>> y
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    y
NameError: name 'y' is not defined
>>> next(g)
0
>>> y
[0, 1]
>>> next(g)
1
>>> y
[0, 1]
>>> next(g)
2
>>> y
[2, 3]

Error Reporting

Currently, the proposed syntax generates a SyntaxError. Allowing these forms to be recognized as syntactically valid requires adjusting the grammar rules for invalid_comprehension and invalid_dict_comprehension to allow the use of * and **, respectively.

Additional specific error messages should be provided in at least the following cases:

• Attempting to use ** in a list comprehension or generator expression should report that dictionary unpacking cannot be used in those structures, for example:

  >>> [**x for x in y]
    File "<stdin>", line 1
      [**x for x in y]
       ^^^
  SyntaxError: cannot use dict unpacking in list comprehension
  
  >>> (**x for x in y)
    File "<stdin>", line 1
      (**x for x in y)
       ^^^
  SyntaxError: cannot use dict unpacking in generator expression
  

• The existing error message for attempting to use * in a dictionary key/value should be retained, but similar messages should be reported when attempting to use ** unpacking on a dictionary key or value, for example:

  >>> {*k: v for k,v in items}
    File "<stdin>", line 1
      {*k: v for k,v in items}
       ^^
  SyntaxError: cannot use a starred expression in a dictionary key
  
  >>> {k: *v for k,v in items}
    File "<stdin>", line 1
      {k: *v for k,v in items}
          ^^
  SyntaxError: cannot use a starred expression in a dictionary value
  
  >>> {**k: v for k,v in items}
    File "<stdin>", line 1
      {**k: v for k,v in items}
       ^^^
  SyntaxError: cannot use dict unpacking in a dictionary key
  
  >>> {k: **v for k,v in items}
    File "<stdin>", line 1
      {k: **v for k,v in items}
          ^^^
  SyntaxError: cannot use dict unpacking in a dictionary value
  

• The phrasing of some other existing error messages should similarly be adjusted to account for the presence of the new syntax, and/or to clarify ambiguous or confusing cases relating to unpacking more generally (particularly those mentioned in Further Generalizing Unpacking Operators), for example:

  >>> [*x if x else y]
    File "<stdin>", line 1
      [*x if x else y]
       ^^^^^^^^^^^^^^
  SyntaxError: invalid starred expression. Did you forget to wrap the conditional expression in parentheses?
  
   >>> {**x if x else y}
    File "<stdin>", line 1
      {**x if x else y}
       ^^^^^^^^^^^^^^^
  SyntaxError: invalid double starred expression. Did you forget to wrap the conditional expression in parentheses?
  
  >>> [x if x else *y]
    File "<stdin>", line 1
      [x if x else *y]
                   ^
  SyntaxError: cannot unpack only part of a conditional expression
  
  >>> {x if x else **y}
    File "<stdin>", line 1
      {x if x else **y}
                   ^^
  SyntaxError: cannot use dict unpacking on only part of a conditional expression
  

Replacing Explicit Loops

Replacing explicit loops compresses multiple lines into one, and avoids the need for defining and referencing an auxiliary variable.

• From email/_header_value_parser.py:

  # current:
  comments = []
  for token in self:
      comments.extend(token.comments)
  return comments
  
  # improved:
  return [*token.comments for token in self]
  

• From shutil.py:

  # current:
  ignored_names = []
  for pattern in patterns:
      ignored_names.extend(fnmatch.filter(names, pattern))
  return set(ignored_names)
  
  # improved:
  return {*fnmatch.filter(names, pattern) for pattern in patterns}
  

• From http/cookiejar.py:

  # current:
  cookies = []
  for domain in self._cookies.keys():
      cookies.extend(self._cookies_for_domain(domain, request))
  return cookies
  
  # improved:
  return [
      *self._cookies_for_domain(domain, request)
      for domain in self._cookies.keys()
  ]
  

Replacing from_iterable and Friends

While not always the right choice, replacing itertools.chain.from_iterable and map can avoid an extra level of redirection, resulting in code that follows conventional wisdom that comprehensions are more readable than map/filter.

• From dataclasses.py:

  # current:
  inherited_slots = set(
      itertools.chain.from_iterable(map(_get_slots, cls.__mro__[1:-1]))
  )
  
  # improved:
  inherited_slots = {*_get_slots(c) for c in cls.__mro__[1:-1]}
  

• From importlib/metadata/__init__.py:

  # current:
  return itertools.chain.from_iterable(
      path.search(prepared) for path in map(FastPath, paths)
  )
  
  # improved:
  return (*FastPath(path).search(prepared) for path in paths)
  

• From collections/__init__.py (Counter class):

  # current:
  return _chain.from_iterable(_starmap(_repeat, self.items()))
  
  # improved:
  return (*_repeat(elt, num) for elt, num in self.items())
  

• From zipfile/_path/__init__.py:

  # current:
  parents = itertools.chain.from_iterable(map(_parents, names))
  
  # improved:
  parents = (*_parents(name) for name in names)
  

• From _pyrepl/_module_completer.py:

  # current:
  search_locations = set(chain.from_iterable(
      getattr(spec, 'submodule_search_locations', [])
      for spec in specs if spec
  ))
  
  # improved:
  search_locations = {
      *getattr(spec, 'submodule_search_locations', [])
      for spec in specs if spec
  }
  

Replacing Double Loops in Comprehensions

Replacing double loops in comprehensions avoids the need for defining and referencing an auxiliary variable, reducing clutter.

• From importlib/resources/readers.py:

  # current:
  children = (child for path in self._paths for child in path.iterdir())
  
  # improved:
  children = (*path.iterdir() for path in self._paths)
  

• From asyncio/base_events.py:

  # current:
  exceptions = [exc for sub in exceptions for exc in sub]
  
  # improved:
  exceptions = [*sub for sub in exceptions]
  

• From _weakrefset.py:

  # current:
  return self.__class__(e for s in (self, other) for e in s)
  
  # improved:
  return self.__class__(*s for s in (self, other))
  

Starred Generators as Function Arguments

One common concern that has arisen multiple times (not only in the discussion threads linked above but also in previous discussions around this same idea) is a possible syntactical ambiguity when passing a starred generator as the sole argument to f(*x for x in y). In the original PEP 448, this ambiguity was cited as a reason for not including a similar generalization as part of the proposal.

This proposal suggests that f(*x for x in y) should be interpreted as f((*x for x in y)) and should not attempt further unpacking of the resulting generator, but several alternatives were suggested in our discussion (and/or have been suggested in the past), including:

• interpreting f(*x for x in y) as f(*(x for x in y),
• interpreting f(*x for x in y) as f(*(*x for x in y)), or
• continuing to raise a SyntaxError for f(*x for x in y) even if the other aspects of this proposal are accepted.

The reason to prefer this proposal over these alternatives is the preservation of existent conventions for punctuation around generator expressions. Currently, the general rule is that generator expressions must be wrapped in parentheses except when provided as the sole argument to a function, and this proposal suggests maintaining that rule even as we allow more kinds of generator expressions. This option maintains a full symmetry between comprehensions and generator expressions that use unpacking and those that don’t.

Currently, we have the following conventions:

f([x for x in y])  # pass in a single list
f({x for x in y})  # pass in a single set
f(x for x in y)  # pass in a single generator (no additional parentheses required around genexp)

f(*[x for x in y])  # pass in elements from the list separately
f(*{x for x in y})  # pass in elements from the set separately
f(*(x for x in y))  # pass in elements from the generator separately (parentheses required)

This proposal opts to maintain those conventions even when the comprehensions make use of unpacking:

f([*x for x in y])  # pass in a single list
f({*x for x in y})  # pass in a single set
f(*x for x in y)  # pass in a single generator (no additional parentheses required around genexp)

f(*[*x for x in y])  # pass in elements from the list separately
f(*{*x for x in y})  # pass in elements from the set separately
f(*(*x for x in y))  # pass in elements from the generator separately (parentheses required)

Further Generalizing Unpacking Operators

Another suggestion that came out of the discussion involved further generalizing the * beyond simply allowing it to be used to unpack the expression in a comprehension. Two main flavors of this extension were considered:

• making * and ** true unary operators that create a new kind of Unpackable object (or similar), which comprehensions could treat by unpacking it but which could also be used in other contexts; or
• continuing to allow * and ** only in the places they are allowed elsewhere in this proposal (expression lists, comprehensions, generator expressions, and argument lists), but also allow them to be used in subexpressions within a comprehension, allowing, for example, the following as a way to flatten a list that contains some iterables but some non-iterable objects:

  [*x if isinstance(x, Iterable) else x for x in [[1,2,3], 4]]
  

These variants were considered substantially more complex (both to understand and to implement) and of only marginal utility, so neither is included in this PEP. As such, these forms should continue to raise a SyntaxError, but with a new error message as described above, though it should not be ruled out as a consideration for future proposals.