tests/utilities/test_compat.py poisons aenum._common.pyver for the whole process, breaking a later import pcapkit

[JarryShaw]

tests/utilities/test_compat.py::test_python35_fallback_implementations fakes sys.version_info = (3, 5) and then executes pcapkit/utilities/compat.py:143, from aenum import StrEnum. On Python ≥ 3.11 that is the first-ever import aenum in the process, so aenum/_common.py:17 caches pyver = (3, 5) permanently. Every later use of aenum in that process is then operating under a false Python version.

The consequence is not subtle: a later import pcapkit dies at aenum/_enum.py:1640 with

AttributeError: 'TransportProtocol' object has no attribute '__set_name__'

because aenum skips the descriptor protocol it believes the running interpreter lacks.

Why it is normally invisible

Masked under pytest by tests/conftest.py's pytest_sessionstart, which imports pcapkit eagerly — so aenum is already imported with the true version before any test runs, and the fake assignment caches nothing new.

So this only bites when aenum has not already been imported: the stdlib unittest runner, a bare script, or any future change to that session hook. Confirmed with a standalone script using neither unittest nor mock.

Why the test cannot simply be left alone

The test is legitimate — it exercises the < 3.6 fallback branch of compat.py. The problem is that faking sys.version_info around a real import leaks state into a third-party module's import-time cache, and no amount of restoring sys.version_info afterwards undoes it, because the damage is a value already memoised in aenum._common.

Suggested directions, not prescribed

1. Import aenum before the fake so the cache is already warm with the true version — smallest change, but relies on ordering that nothing enforces.
2. Run the fallback branch in a subprocess, so the poisoned cache dies with it. Most robust; costs a process per test.
3. Reload aenum._common afterwards — fragile, since other modules hold references to the cached value.

Whichever is chosen, a regression test should assert aenum._common.pyver matches the real interpreter after the suite, since that is the invariant being broken.

Provenance

Found by #686's worker while auditing sys.modules leakage for #674, and deliberately not fixed there — it is a different mechanism (a third-party import-time cache, not sys.modules) and tests/utilities/test_compat.py was outside that PR's scope. Reproduction is its measurement; I have not independently re-run it.

Related: #674 (the sys.modules restoration gap, fixed in #686) and the tests/cli/test_main.py leak filed alongside this.

[JarryShaw]

Reproduced on f0999858e before fixing it, and one part of the premise here needs
correcting — in a direction that makes the defect a little worse than filed.

The reproduction stands, verbatim. python -m unittest tests.utilities.test_compat tests.project.test_public_api on CPython 3.14.7 gives Ran 14 tests /
FAILED (errors=10), all ten being AttributeError: 'TransportProtocol' object has no attribute '__set_name__' raised at aenum/_enum.py:1640 from
pcapkit/const/reg/apptype.py:26. pytest -p no:randomly --noconftest -q over the same
two files gives 10 failed, 4 passed. Each file alone passes.

"On Python ≥ 3.11" is true of this test file, but not of the hazard. Below 3.11 the
real branch of compat.py is itself from aenum import StrEnum, and setUp executes
the real module before every test, so on 3.10 aenum is always already warm when the fake
goes in and the file passes. But faking the version around aenum's first ever import in
a fresh 3.10.21 process does not quietly poison a cache — it takes the import down:

ImportError: cannot import name 'FlagBoundary' from 'enum'
AttributeError: 'FlagBoundary' object has no attribute '__set_name__'

from aenum's own fallback definition of FlagBoundary. So what protects 3.10 today is
an incidental ordering inside setUp, not a structural guarantee, and pre-importing
aenum is load-bearing there too.

Suggested direction 3 is dead on measurement, which is worth recording since the
issue offers it: aenum/_enum.py:2 is from ._common import *, so pyver is copied
into every aenum module's globals and _enum.py:1640 branches on its own copy.
importlib.reload(aenum._common) gives _common.pyver == (3, 14) and leaves
_enum.pyver == (3, 5) — it repairs the reading nobody reads.

Direction 2 is rejected on coverage, also measured: [tool.coverage.run] here is
source = ["pcapkit"] with no parallel/concurrency and no COVERAGE_PROCESS_START
.pth, and coverage keys on file path, so the in-process load_module(…, 'pcapkit/utilities/compat.py') is what credits that file's < 3.6, < 3.8, < 3.9
and < 3.11 branches today. A subprocess would drop the measurement.

Fixed in #693 by direction 1, with the ordering asserted rather than assumed — the
window between installing and removing the fake is measured, and any name first-imported
inside it fails the test at the line that caused it. The aenum pyver assertion you
asked for is there, swept across every aenum module that holds one rather than just
_common, and runs as a cleanup after every test in the file.