Syntax

Die Grammatik sollte geändert werden, um den Ausdruck in Listen-/Mengen-Comprehensions und Generator Expressions mit einem * präzedieren zu lassen, und um eine alternative Form der Dictionary-Comprehensions zu ermöglichen, bei der ein doppelt gestarner Ausdruck anstelle eines key: value-Paares verwendet werden kann.

Dies kann durch Aktualisierung der listcomp und setcomp Regeln geschehen, um star_named_expression anstelle von named_expression zu verwenden

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

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

Die Regel für genexp müsste ähnlich modifiziert werden, um einen starred_expression zuzulassen

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

Die Regel für Dictionary-Comprehensions müsste ebenfalls angepasst werden, um diese neue Form zu ermöglichen

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

Es sollte keine Änderung an der Art und Weise vorgenommen werden, wie Argument-Unpacking in Funktionsaufrufen gehandhabt wird, d.h. die allgemeine Regel, dass Generator Expressions, die als einziges Argument an Funktionen übergeben werden, keine zusätzlichen redundanten Klammern benötigen, sollte beibehalten werden. Beachten Sie, dass dies impliziert, dass zum Beispiel f(*x for x in it) äquivalent zu f((*x for x in it)) ist (siehe Gestarnt Generatoren als Funktionsargumente für weitere Diskussionen).

* und ** sollten nur auf der obersten Ebene des Ausdrucks in der Comprehension erlaubt sein (siehe Weitere Verallgemeinerung von Unpacking-Operatoren für weitere Diskussionen).

Semantik: Listen-/Mengen-/Dictionary-Comprehensions

Die Bedeutung eines gestarnten Ausdrucks in einer Listen-Comprehension [*expr for x in it] besteht darin, jeden Ausdruck als Iterable zu behandeln und sie zu verketten, auf dieselbe Weise, als wären sie explizit über [*expr1, *expr2, ...] aufgelistet. Ebenso bildet {*expr for x in it} eine Mengenunion, als wären die Ausdrücke explizit über {*expr1, *expr2, ...} aufgelistet; und {**expr for x in it} kombiniert Dictionaries, als wären die Ausdrücke explizit über {**expr1, **expr2, ...} aufgelistet. Diese Operationen sollten alle äquivalenten Semantiken für die Kombination von Sammlungen auf diese Weise beibehalten (einschließlich zum Beispiel, dass spätere Werte frühere bei einem duplizierten Schlüssel beim Kombinieren von Dictionaries ersetzen).

Anders ausgedrückt, die Objekte, die von den folgenden Comprehensions erstellt werden

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

sollten äquivalent zu den Objekten sein, die von den folgenden Codefragmenten erstellt werden, jeweils

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)

Semantik: Generator Expressions

Generator Expressions, die die Unpacking-Syntax verwenden, sollten neue Generatoren bilden, die Werte aus der Verkettung der von den Ausdrücken bereitgestellten Iterables erzeugen. Insbesondere ist das Verhalten definiert als äquivalent zum folgenden

# equivalent to g = (*expr for x in it)
def generator():
    for x in it:
        yield from expr

g = generator()

Da yield from in asynchronen Generatoren nicht erlaubt ist (siehe Abschnitt PEP 525 über asynchrones yield from), ist das Äquivalent für (*expr async for x in ait()) eher wie folgt (obwohl diese neue Form natürlich die Schleifenvariable i nicht definieren oder referenzieren sollte)

# equivalent to g = (*expr async for x in ait())
async def generator():
    async for x in ait():
        for i in expr:
            yield i

g = generator()

Die Details dieser Semantik sollten in Zukunft noch einmal überdacht werden, insbesondere wenn asynchrone Generatoren Unterstützung für yield from erhalten (in diesem Fall könnte die asynchrone Variante geändert werden, um yield from anstelle einer expliziten Schleife zu verwenden). Siehe Alternative Semantik für Generator Expressions für weitere Diskussionen.

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]

Fehlermeldung

Derzeit erzeugt die vorgeschlagene Syntax einen SyntaxError. Damit diese Formen als syntaktisch gültig anerkannt werden, müssen die Grammatikregeln für invalid_comprehension und invalid_dict_comprehension angepasst werden, um die Verwendung von * bzw. ** zuzulassen.

Zusätzliche spezifische Fehlermeldungen sollten zumindest in den folgenden Fällen bereitgestellt werden

• Der Versuch, ** in einer Listen-Comprehension oder Generator Expression zu verwenden, sollte melden, dass Dictionary-Unpacking in diesen Strukturen nicht verwendet werden kann, zum Beispiel

  >>> [**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
  

• Die bestehende Fehlermeldung für den Versuch, * bei einem Dictionary-Schlüssel/Wert zu verwenden, sollte beibehalten werden, aber ähnliche Meldungen sollten ausgegeben werden, wenn versucht wird, **-Unpacking auf einen Dictionary-Schlüssel oder -Wert anzuwenden, zum Beispiel

  >>> {*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
  

• Die Formulierung einiger anderer bestehender Fehlermeldungen sollte ebenfalls angepasst werden, um die neue Syntax zu berücksichtigen und/oder unklare oder verwirrende Fälle im Zusammenhang mit Unpacking im Allgemeinen zu klären (insbesondere die Fälle, die in Weitere Verallgemeinerung von Unpacking-Operatoren erwähnt werden), zum Beispiel

  >>> [*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
  

Ersetzen expliziter Schleifen

Das Ersetzen expliziter Schleifen komprimiert mehrere Zeilen auf eine und vermeidet die Notwendigkeit, eine Hilfsvariable zu definieren und zu referenzieren.

• Aus 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]
  

• Aus 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}
  

• Aus 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()
  ]
  

Ersetzen von `from_iterable` und Freunden

Obwohl nicht immer die richtige Wahl, kann das Ersetzen von itertools.chain.from_iterable und map eine zusätzliche Ebene der Umleitung vermeiden, was zu Code führt, der der konventionellen Weisheit folgt, dass Comprehensions besser lesbar sind als map/filter.

• Aus 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]}
  

• Aus 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)
  

• Aus collections/__init__.py (Klasse Counter)

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

• Aus zipfile/_path/__init__.py

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

• Aus _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
  }
  

Ersetzen von doppelten Schleifen in Comprehensions

Das Ersetzen von doppelten Schleifen in Comprehensions vermeidet die Notwendigkeit, eine Hilfsvariable zu definieren und zu referenzieren, und reduziert Unordnung.

• Aus 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)
  

• Aus asyncio/base_events.py

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

• Aus _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))
  

Gestarnt Generatoren als Funktionsargumente

Ein häufiges Bedenken, das mehrmals aufkam (nicht nur in den oben verlinkten Diskussionsfäden, sondern auch in früheren Diskussionen über diese gleiche Idee), ist eine mögliche syntaktische Mehrdeutigkeit beim Übergeben eines gestarnten Generators als einziges Argument an f(*x for x in y). Im ursprünglichen PEP 448 wurde diese Mehrdeutigkeit als Grund dafür angeführt, keine ähnliche Verallgemeinerung als Teil des Vorschlags aufzunehmen.

Dieser Vorschlag legt nahe, dass f(*x for x in y) als f((*x for x in y)) interpretiert werden sollte und kein weiteres Unpacking des resultierenden Generators versuchen sollte, aber mehrere Alternativen wurden in unserer Diskussion vorgeschlagen (und/oder wurden in der Vergangenheit vorgeschlagen), darunter

• Interpretation von f(*x for x in y) als f(*(x for x in y),
• Interpretation von f(*x for x in y) als f(*(*x for x in y)), oder
• weiterhin einen SyntaxError für f(*x for x in y) auszulösen, auch wenn die anderen Aspekte dieses Vorschlags akzeptiert werden.

Der Grund, diesen Vorschlag gegenüber diesen Alternativen zu bevorzugen, ist die Beibehaltung bestehender Konventionen für die Satzzeichen um Generator Expressions. Derzeit ist die allgemeine Regel, dass Generator Expressions in Klammern gesetzt werden müssen, es sei denn, sie werden als einziges Argument an eine Funktion übergeben, und dieser Vorschlag schlägt vor, diese Regel auch dann beizubehalten, wenn wir mehr Arten von Generator Expressions zulassen. Diese Option erhält eine vollständige Symmetrie zwischen Comprehensions und Generator Expressions, die Unpacking verwenden, und denen, die es nicht tun.

Derzeit haben wir die folgenden Konventionen

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)

Dieser Vorschlag optiert dafür, diese Konventionen beizubehalten, auch wenn die Comprehensions Unpacking verwenden

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)

Weitere Verallgemeinerung von Unpacking-Operatoren

Ein weiterer Vorschlag, der aus der Diskussion hervorgegangen ist, betraf die weitere Verallgemeinerung von * über die bloße Zulassung der Verwendung zum Unpacking des Ausdrucks in einer Comprehension hinaus. Zwei Hauptvarianten dieser Erweiterung wurden in Betracht gezogen

• machen * und ** zu echten unären Operatoren, die eine neue Art von Unpackable-Objekt (oder ähnlich) erstellen, das Comprehensions durch Unpacking behandeln könnten, das aber auch in anderen Kontexten verwendet werden könnte; oder
• weiterhin * und ** nur an den Stellen zuzulassen, an denen sie an anderer Stelle in diesem Vorschlag erlaubt sind (Ausdruckslisten, Comprehensions, Generator Expressions und Argumentlisten), aber sie auch in Teilausdrücken innerhalb einer Comprehension zu verwenden, was zum Beispiel Folgendes als Möglichkeit zur Abflachung einer Liste ermöglicht, die einige Iterables, aber einige nicht-iterierbare Objekte enthält

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

Diese Varianten wurden als erheblich komplexer (sowohl im Verständnis als auch in der Implementierung) und von nur marginalem Nutzen erachtet, so dass keine davon in diesem PEP enthalten ist. Daher sollten diese Formen weiterhin einen SyntaxError auslösen, jedoch mit einer neuen Fehlermeldung wie oben beschrieben, obwohl dies nicht als zukünftiger Vorschlag ausgeschlossen werden sollte.

Alternative Semantik für Generator Expressions

Ein weiterer Diskussionspunkt drehte sich um die Semantik des Unpackings in Generator Expressions, insbesondere die Beziehung zwischen der Semantik von synchronen und asynchronen Generator Expressions, da asynchrone Generatoren yield from nicht unterstützen (siehe Abschnitt PEP 525 über asynchrone yield from).

Die Kernfrage drehte sich darum, ob synchrone und asynchrone Generator Expressions yield from (oder ein Äquivalent) beim Unpacking verwenden sollten, im Gegensatz zu einer expliziten Schleife. Der Hauptunterschied zwischen diesen Optionen ist, ob der resultierende Generator an die entpackten Objekte delegiert, was das Verhalten dieser Generator Expressions bei Verwendung mit .send()/.asend(), .throw()/.athrow() und .close()/.aclose() beeinflussen würde, falls die entpackten Objekte selbst Generatoren sind. Die Unterschiede zwischen diesen Optionen sind in Anhang: Semantik der Generator-Delegation zusammengefasst.

Mehrere vernünftige Optionen wurden in Betracht gezogen, von denen keine eine klare Siegerin in einer Umfrage im Discourse-Thread war. Abgesehen von dem oben skizzierten Vorschlag wurden auch die folgenden in Betracht gezogen

1. Verwendung expliziter Schleifen sowohl für synchrone als auch für asynchrone Generator Expressions.

   Diese Strategie hätte zu einer Symmetrie zwischen synchronen und asynchronen Generator Expressions geführt, aber ein potenziell nützliches Werkzeug verhindert, indem die Delegation im Fall von synchronen Generator Expressions nicht zugelassen wird. Ein spezifisches Bedenken bei diesem Ansatz ist die Einführung einer Asymmetrie zwischen synchronen und asynchronen Generatoren, aber dieses Bedenken wird gemildert durch die Tatsache, dass diese Asymmetrien bereits zwischen synchronen und asynchronen Generatoren im Allgemeinen bestehen.

2. Verwendung von yield from zum Unpacking in synchronen Generator Expressions und Nachahmung des Verhaltens von yield from zum Unpacking in asynchronen Generator Expressions.

   Diese Strategie würde auch das Unpacking in synchronen und asynchronen Generatoren symmetrisch verhalten lassen, aber sie wäre auch komplexer, genug, dass der Aufwand den Nutzen möglicherweise nicht wert ist. Daher schlägt dieser PEP vor, dass Generator Expressions, die den Unpacking-Operator verwenden, keine Semantik ähnlich yield from verwenden sollten, bis yield from generell in asynchronen Generatoren unterstützt wird.

3. Verwendung von yield from zum Unpacking in synchronen Generator Expressions und Verbot des Unpackings in asynchronen Generator Expressions, bis diese yield from unterstützen.

   Diese Strategie könnte möglicherweise die Reibung verringern, wenn asynchrone Generator Expressions die Unterstützung für yield from in Zukunft erhalten, indem sichergestellt wird, dass jede Entscheidung, die dann getroffen wird, vollständig abwärtskompatibel ist. Aber der Nutzen des Unpackings in diesem Kontext scheint den potenziellen Nachteil einer minimal-invasiven abwärtsinkompatiblen Änderung in der Zukunft zu überwiegen, falls asynchrone Generator Expressions Unterstützung für yield from erhalten.

4. Verbot des Unpackings in allen Generator Expressions.

   Dies würde die Symmetrie zwischen beiden Fällen beibehalten, jedoch mit dem Nachteil des Verlusts einer sehr ausdrucksstarken Form.

Jede dieser Optionen (einschließlich der in diesem PEP vorgestellten) hat ihre Vor- und Nachteile, wobei keine Option in allen Punkten klar überlegen ist. Die in Semantik: Generator Expressions vorgeschlagene Semantik stellt einen vernünftigen Kompromiss dar, bei dem das Unpacking in sowohl synchronen als auch asynchronen Generator Expressions die gängigen Wege widerspiegelt, wie äquivalente Generatoren derzeit geschrieben werden. Darüber hinaus sind diese subtilen Unterschiede unwahrscheinlich, Auswirkungen auf gängige Anwendungsfälle zu haben (zum Beispiel gibt es keinen Unterschied für den wahrscheinlich häufigsten Anwendungsfall, einfache Sammlungen zu kombinieren).

Wie oben vorgeschlagen, sollte diese Entscheidung im Falle einer zukünftigen Unterstützung von asynchronen Generatoren für yield from überdacht werden. In diesem Fall sollte die Anpassung der Semantik des Unpackings in asynchronen Generator Expressions zur Verwendung von yield from in Betracht gezogen werden.

Grundlegendes Verhalten

Für einfache Iterationen über Werte, was voraussichtlich die mit Abstand häufigste Verwendung von Entpackungen in Generatorausdrücken sein wird, liefern beide Ansätze identische Ergebnisse.

def yield_from(iterables):
    for iterable in iterables:
        yield from iterable

def explicit_loop(iterables):
    for iterable in iterables:
        for item in iterable:
            yield item

# Both produce the same sequence of values
x = list(yield_from([[1, 2], [3, 4]]))
y = list(explicit_loop([[1, 2], [3, 4]]))
print(x == y)  # prints True

Unterschiede im fortgeschrittenen Generator-Protokoll

Die Unterschiede werden deutlich, wenn die fortgeschrittenen Generatorprotokollmethoden .send(), .throw() und .close() verwendet werden und wenn die Unter-Iterierbaren selbst Generatoren anstelle einfacher Sequenzen sind. In diesen Fällen führt die yield from-Version dazu, dass das zugehörige Signal den Subgenerator erreicht, die Version mit der expliziten Schleife jedoch nicht.

def sub_generator():
    x = yield "first"
    yield f"received: {x}"
    yield "last"

def yield_from():
    yield from sub_generator()

def explicit_loop():
    for item in sub_generator():
        yield item

# With yield from, values are passed through to sub-generator
gen1 = yield_from()
print(next(gen1))  # prints "first"
print(gen1.send("hello"))  # prints "received: hello"
print(next(gen1))  # prints "last"

# With explicit loop, .send() affects the outer generator; values don't reach the sub-generator
gen2 = explicit_loop()
print(next(gen2))  # prints "first"
print(gen2.send("hello"))  # prints "received: None" (sub-generator receives None instead of "hello")
print(next(gen2))  # prints "last"

def sub_generator_with_exception_handling():
    try:
        yield "first"
        yield "second"
    except ValueError as e:
        yield f"caught: {e}"

def yield_from():
    yield from sub_generator_with_exception_handling()

def explicit_loop():
    for item in sub_generator_with_exception_handling():
        yield item

# With yield from, exceptions are passed to sub-generator
gen1 = yield_from()
print(next(gen1))  # prints "first"
print(gen1.throw(ValueError("test")))  # prints "caught: test"

# With explicit loop, exceptions affect the outer generator only
gen2 = explicit_loop()
print(next(gen2))  # prints "first"
print(gen2.throw(ValueError("test")))  # ValueError is raised; sub-generator doesn't see it

# hold references to sub-generators so GC doesn't close the explicit loop version
references = []

def sub_generator_with_cleanup():
    try:
        yield "first"
        yield "second"
    finally:
        print("sub-generator received GeneratorExit")

def yield_from():
    try:
        g = sub_generator_with_cleanup()
        references.append(g)
        yield from g
    finally:
        print("outer generator received GeneratorExit")

def explicit_loop():
    try:
        g = sub_generator_with_cleanup()
        references.append(g)
        for item in g:
            yield item
    finally:
        print("outer generator received GeneratorExit")

# With yield from, GeneratorExit is passed through to sub-generator
gen1 = yield_from()
print(next(gen1))  # prints "first"
gen1.close()  # closes sub-generator and then outer generator

# With explicit loop, GeneratorExit goes to outer generator only
gen2 = explicit_loop()
print(next(gen2))  # prints "first"
gen2.close()  # only closes outer generator

print('program finished; GC will close the explicit loop subgenerator')
# second inner generator closes when GC closes it at the end