You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Devguide recommends a very slow testing configuration #1895
Describe the enhancement or feature you would like
At the PyCon AU sprints, I found that running the test suite in parallel with make test under --with-pydebug on my machine took ~3.5 minutes, while running with the default configuration took ~1 minute.
Running the test suite sequentially with python -m test took ~18 minutes on a default build, while --with-pydebug took ~27 minutes.
One of the sprint attendees (with a much slower system in general) had their sequential test run take ~45 minutes under --with-pydebug, dropping to around ~25 minutes when using the default build configuration, and then down to ~5 minutes by running with make test rather than python -m test.
between the intro, the table of section references, and the video embed, the "Quick reference" link has dropped "below the fold" on the landing page (at least on my laptop screen)
some of the instructions were originally written for C-focused development and then never revisited for pure Python contributors
we're inconsistent in our recommendations for how to run the test suite (and we don't emphasise how slow it is to run them sequentially, so you almost never want to actually do that if you can avoid it)
One change I think would be worth making is to recommend an unqualified make as the default build configuration (especially when working pure Python changes without touching any of the C code), and mention make --with-pydebug as an option that is slower in execution, but provides a much better debugging experience when working on C level changes (with reference to https://docs.python.org/3/using/configure.html#python-debug-build)
Another would be to move the quick reference section heading and linking paragraph up above the section link table.
Most people have multicore, so parallel testing is a good default.
A couple of ideas:
Add -j0 to all the examples, except change the current "If you have a multi-core or multi-CPU machine, you can enable parallel testing using several Python processes so as to speed up things:" into how to run single process instead (--single-process).
Change the python -m test default in CPython's regrtest to -j0 by default. Most of our CI uses --fast-ci/--slow-ci which already set -j0. We'd need to update some other places to explicitly use --single-process, such as PGO training, and update the devguide's "If you have a multi-core..." example as above.
Activity
hugovk commentedon Aug 30, 2026
Most people have multicore, so parallel testing is a good default.
A couple of ideas:
Add
-j0to all the examples, except change the current "If you have a multi-core or multi-CPU machine, you can enable parallel testing using several Python processes so as to speed up things:" into how to run single process instead (--single-process).Change the
python -m testdefault in CPython's regrtest to-j0by default. Most of our CI uses--fast-ci/--slow-ciwhich already set-j0. We'd need to update some other places to explicitly use--single-process, such as PGO training, and update the devguide's "If you have a multi-core..." example as above.