python / python/cpython

test.support.warnings_helper.check_warnings() raises KeyError: 'warnings' under -X lazy_imports=all

Aberta
#156,570 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

tests type-bug
Linguagem predominante
Python
Estrelas
77.2k
Forks
36k
Métricas de merge de PRs
Métricas de PR pendentes

Descrição

Bug report

test.support.warnings_helper.check_warnings() raises KeyError: 'warnings'
under -X lazy_imports=all, taking down every test that uses it.

Reproducer:

./python -X lazy_imports=all -m test test_sundry test_time

Lib/test/support/warnings_helper.py:176:

# Because test_warnings swap the module, we need to look up in the
# sys.modules dictionary.
wmod = sys.modules['warnings']

warnings is not in sys.modules at interpreter startup, with or without lazy
imports, so that key is populated solely by the module-level import warnings
at the top of this same file. Reading the module out of sys.modules by
subscript means the global name is never touched, so under lazy imports the
import is never resolved and the key is never created.

41 files under Lib/test/ use check_warnings() / check_no_warnings().

One-line fix — the default argument is evaluated on every call, which resolves
the lazy import before the lookup, and the module swap done by test_warnings
still wins:

wmod = sys.modules.get('warnings', warnings)

Verified on main (d9154924138): with that change test_sundry, test_time
and test_warnings pass under -X lazy_imports=all; test___all__,
test_sundry, test_time, test_warnings and test_support still pass
without the flag.

test_sundry and test_time are not in the exclusion list proposed in
GH-151105, so this is a failure mode the planned CI would not have covered.

The same pattern appears in the tests themselves. After the helper is fixed,
test___all__ still fails at Lib/test/test___all__.py:49:

if not hasattr(sys.modules[modname], "__all__"):

with KeyError: '_osx_support' — the module is imported by
exec("import %s" % modname) a few lines above, which under lazy imports
leaves sys.modules untouched. Lines 71 and 76 do the same thing.

grep -rn 'sys\.modules\[' Lib/test/ reports 126 subscript reads. Most are
legitimate identity checks after an eager import; the ones worth auditing are
those where the key is expected to be filled by an import in the same file, or
by an execed import statement.

Related to #149640.

CPython versions tested on:

CPython main branch (d9154924138)

Operating systems tested on:

Linux


🤖 Investigated and drafted with Claude Code,
model Claude Opus 5 (1M context).

Linked PRs
  • gh-156573

Guia de contribuição

Abrir o guia de contribuição

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.

Direção de pesquisa

Comece em Lib/test/support/warnings_helper.py na linha 176 e, em seguida, inspecione os acessos a sys.modules relatados em Lib/test/test___all__.py. Execute o reproducer com -X lazy_imports=all e os módulos de teste listados; considera-se concluído quando os testes afetados passam tanto com quanto sem lazy imports, incluindo test_support e test_warnings.

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

Avaliação

Stack de tecnologia
python
Domínio
testing-qa
Tipo de issue
Bug
Dificuldade
2/5
Tempo estimado
1-3 horas
Status de atividade
Estagnada
Clareza
Claramente especificada
Facilidade para iniciantes
25/100

Receba novas issues na sua caixa de entrada

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