Skip to content

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

Description

@ashm-dev

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 (d915492): 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 (d915492)

Operating systems tested on:

Linux


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

Linked PRs

Activity

  1. added 2 commits that reference this issue on Aug 29, 2026
  2. mikemikimike commented on Aug 29, 2026

    @mikemikimike

    I have opened PR #156573 with a minimal fix and regression coverage.

    The patch changes _filterwarnings() to use the already imported warnings module when lazy imports have not populated sys.modules, and adds a focused test for that state. I also added the required Misc/NEWS.d entry.

    Local verification completed:

    • python Lib/test/test_warnings_helper.py — passed
    • python -m py_compile Lib/test/support/warnings_helper.py Lib/test/test_warnings_helper.py — passed
    • git diff --check — passed

    The PR's GitHub checks are still running. The initial status showed the expected CPython CLA check failure for the account and a missing-news failure; the news entry has now been pushed, so the checks should refresh.

    PR: #156573

  3. added a commit that references this issue on Aug 29, 2026
  4. added a commit that references this issue on Aug 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    testsTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions