Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#160,299 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
Python
Estrelas
77.7k
Forks
38.3k
Merge médio
14h 29min
PRs com merge (30d)
699

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de python/cpython

Todas as issues de python/cpython

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.