Order-dependent failure: test_profiling CLI test fails after test_importlib.test_util

[zainnadeem786]

Bug report

Bug description:

Summary

I found an order-dependent test failure on current main.

A test_profiling sampling CLI test passes when run alone, but fails when run after test_importlib.test_util.

Environment

• OS: Windows NT 10.0.26200.0
• CPython commit: 449122ed0dbdb6a545af4927c59f4c80ee15c515
• Debug build: PCbuild\amd64\python_d.exe
• Release build: also reproduced
• Branch: investigate/deep-cpython-bug-hunt

Reproduction

PCbuild\amd64\python_d.exe -m unittest -v test.test_importlib.test_util test.test_profiling.test_sampling_profiler.test_cli.TestSampleProfilerCLI.test_cli_module_argument_parsing

The same profiling test passes when run alone.

Actual behavior

The test fails with:

profiling.sampling.errors.SamplingModuleNotFoundError: Module 'mymodule' not found.

Expected behavior

The profiling CLI test should pass regardless of whether test_importlib.test_util ran earlier in the same process.

Investigation

The profiling CLI test patches:

importlib.util.find_spec

However, after running test_importlib.test_util, importlib.util and sys.modules["importlib.util"] appear to refer to different module objects.

The CLI code calls through its own imported module reference:

profiling.sampling.cli.importlib.util.find_spec

So the mock on the global importlib.util.find_spec does not intercept the lookup, and the CLI tries to resolve the fake module name normally.

That leads to:

SamplingModuleNotFoundError: Module 'mymodule' not found.

I could not find an existing open issue or PR covering this failure.

Possible fix

The smallest fix may be to patch the symbol at the point where it is used, for example:

profiling.sampling.cli.importlib.util.find_spec

inside the profiling CLI tests, or alternatively to avoid this mock by using a real temporary module.

I am happy to prepare a focused test-only PR if that direction sounds reasonable.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

• gh-152659: Preserve parent package attributes when restoring fresh imports #152675

[StanFromIreland]

The smallest fix may be to patch the symbol at the point where it is used, for example:

I think we should fix import_fresh_module instead.

[zainnadeem786]

Thanks! I'll investigate import_fresh_module as the potential root cause. If the investigation confirms it, I'll prepare a focused PR addressing that instead of patching the profiling test directly.

[zainnadeem786]

Thanks for the suggestion. I investigated import_fresh_module() and found it restores sys.modules but not the corresponding parent package attributes. I've prepared a fix and will open a PR shortly for review.