Repository navigation
__lazy_import__ errors in test_xpickle #144878
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Feb 16, 2026 First thought: it might be worth
make cleanand rebuilding the CPython source?The lazy imports PEP was merged to
mainlast week, so that needs to be rebuilt: #142351Reacted by Stan UlbrychI've already done that. When seeing anything which might mess up
make(dependencies aren't perfect) I typically start withgit clean -fdx. I'll try again later (not at home right now) just to make sure I'm not misremembering.- addedtestsTests in the Lib/test dirTests in the Lib/test dirpendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
on Feb 16, 2026 Just to confirm, on both Linux and Mac (Git checkout up-to-date) I executed:
git clean -fdx && ./configure && nice make test TESTOPTS=-ucpu,largefile,extralargefile,xpickle ./python.exe -m test -v -uxpickle test_xpickle(just
./pythonon Linux)and got the same slew of tracebacks when run as part of
make testor standalone.Is it possible the failure stems from lazy imports not being suitably skipped when running
xpickletests on older versions of Python?You should only run the tests in
mainon CPython built frommain.Older Python versions should not run against the tests in
mainbecause they don't support the new things that are only inmain, such asbuiltins.__lazy_import__.That's how I run it. But it pokes around my machines to find older versions for which to check compatibility. Look at the first line of the traceback. It's failing in something like
...CPicklePython314Compat.... All the other tracebacks are either different protocol numbers 0 thru 5) or different Python combinations. It finds ten different Python versions on my Mac, so that same traceback is spewed sizes of times. The result is the same on Linux, though I have many fewer Python versions, so I get fewer tracebacks.Reacted by Hugo van KemenadeAha, right, I can reproduce (on macOS) it when running either
./python.exe Lib/test/test_xpickle.pyor:❯ ./python.exe -m test test_xpickle -u xpickle Raised RLIMIT_NOFILE: 256 -> 1024 Using random seed: 1869269231 0:00:00 load avg: 5.00 Run 1 test sequentially in a single process 0:00:00 load avg: 5.00 [1/1] test_xpickle test test_xpickle failed -- multiple errors occurred; run in verbose mode for details 0:00:16 load avg: 4.41 [1/1/1] test_xpickle failed (126 errors) == Tests result: FAILURE == 1 test failed: test_xpickle Total duration: 16.7 sec Total tests: run=1,456 skipped=98 Total test files: run=1/1 failed=1 Result: FAILURE
By default we don't test with the
xpickleresource:xpickle - Test pickle and _pickle against Python 3.6, 3.7, 3.8 and 3.9 to test backwards compatibility. These tests may take very long to complete.But it appears we don't have it enabled for either GitHub Actions or buildbots, which seems like a shortcoming.
Anyway, thanks for the report, and ping @DinoV and @pablogsal about this bug.
- removedpendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
on Feb 16, 2026 - added a commit that references this issue
on Feb 16, 2026 #144889 should do the trick
Reacted by Hugo van KemenadeThanks @smontanaro for the report!
Reacted by Hugo van Kemenade
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
Bug report
Bug description:
test_xpickleseems to be failing with the above traceback for every version it's tested with and for all protocols. I have a bunch of versions available, 2.7 and 3.7-3.14 in addition to main. The above traceback is from my Mac, but I get the same failure on my Linux laptop.CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux, macOS
Linked PRs