Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

symtable: a name read only inside an inlined comprehension is not marked as referenced (3.12+)

Offen
  • Stimmt etwas nicht?
#160,299 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
backend

Rechercherichtung

Start with the symtable handling of inlined comprehensions and the related changes in gh-109292 and gh-124697. Run the reproduction across Python 3.12 and 3.14, then compare the symbol table output with the expected reference for k in f. Done means the enclosing function reports the read or symtable exposes it another way, with tests covering the behavior.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

interpreter-core type-bug

Bug report

Bug description

Since PEP 709 (3.12), symtable no longer creates a child table for a list, set or dict comprehension. The 3.12
What's New says the comprehension's locals now appear in the enclosing function's table (gh-109292).

However, a name from the enclosing scope that is read only inside the inlined comprehension is no longer marked
as referenced in the enclosing function's table, and no child table records the read either. The read becomes
invisible to symtable users. On 3.9 (and, as far as I know, up to 3.11), the read appears in the comprehension's own
listcomp table. Generator expressions, which are still separate scopes, are unaffected.

Reproduction:

"""Minimal reproduction: since PEP 709 (Python 3.12), a name read only inside an inlined list comprehension is not
marked as referenced in the enclosing function's symbol table, and no child table holds it either.
Run with several interpreters: python3.9 shows the read (in a 'listcomp' child table); 3.12 and 3.14 lose it."""
import symtable, sys

SRC = '''
def f(xs, k):
    return [x + k for x in xs]      # list comprehension: inlined since 3.12

def g(xs, k):
    return list(x + k for x in xs)  # generator expression: still its own scope
'''

def report():
    top = symtable.symtable(SRC, "<repro>", "exec")
    for fn in top.get_children():
        if fn.get_name() not in ("f", "g"):
            continue                 # skip implicit scopes such as __annotate__ (3.14)
        k = fn.lookup("k")
        children = {c.get_name(): sorted(s.get_name() for s in c.get_symbols() if s.is_referenced())
                    for c in fn.get_children()}
        print(f"{sys.version.split()[0]}  {fn.get_name()}: k.is_referenced() = {k.is_referenced()};  "
              f"child tables (referenced names) = {children}")

if __name__ == "__main__":
    report()

Output (macOS; CPython 3.9.6, 3.12.12, 3.14.7):

3.9.6  f: k.is_referenced() = False;  child tables (referenced names) = {'listcomp': ['k', 'x']}
3.9.6  g: k.is_referenced() = False;  child tables (referenced names) = {'genexpr': ['k', 'x']}
3.12.12  f: k.is_referenced() = False;  child tables (referenced names) = {}
3.12.12  g: k.is_referenced() = False;  child tables (referenced names) = {'genexpr': ['k', 'x']}
3.14.7  f: k.is_referenced() = False;  child tables (referenced names) = {}
3.14.7  g: k.is_referenced() = False;  child tables (referenced names) = {'genexpr': ['k', 'x']}

Expected: in f, k.is_referenced() should be True, since k is read in f's body now that the comprehension
is part of f's scope. Alternatively, symtable should expose the inlined comprehension's references some other way.

Impact: tools that use symtable to find unused parameters or variables, or dead code, get false "unused"
results. In a scan of 35,562 function scopes, this caused 1,885 false disagreements against the compiled bytecode.

Related: gh-109292 (the documentation of the PEP 709 change to symtable); gh-124697 (refactoring of inlined
comprehensions), which may already fix this on main. I have not tested 3.15 / main.

CPython versions tested on:

3.12, 3.14

Operating systems tested on:

macOS

Linked PRs
  • gh-160413
  • gh-160457
Vorherrschende Sprache
Python
Sterne
77.7k
Forks
38.3k
Ø Merge
13 Std. 30 Min.
Gemergte PRs (30 T.)
708

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus python/cpython

Alle Issues in python/cpython

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.