We should try to figure out which packages already have tests that use threads.
Identifying packages that don't use threads in their tests tells us where in the ecosystem we have poor multithreaded test coverage. Packages with multithreaded tests might also be useful to use to test many pacakges at once by exercising dependencies. Custom multithreaded tests are hard to write and somewhat rare, so identifying more would be valuable.
You could do this by downloading the sdists for e.g. the top 1000 packages on pypi and grepping for ThreadPoolExecutor and import threading in test files.
This comes from speaking @jonkiparsky at the PyCon sprints, thinking about how someone who does not have experience with C extensions can usefully contribute.
We should try to figure out which packages already have tests that use threads.
Identifying packages that don't use threads in their tests tells us where in the ecosystem we have poor multithreaded test coverage. Packages with multithreaded tests might also be useful to use to test many pacakges at once by exercising dependencies. Custom multithreaded tests are hard to write and somewhat rare, so identifying more would be valuable.
You could do this by downloading the sdists for e.g. the top 1000 packages on pypi and grepping for
ThreadPoolExecutorandimport threadingin test files.This comes from speaking @jonkiparsky at the PyCon sprints, thinking about how someone who does not have experience with C extensions can usefully contribute.