Given that the warnings module is not thread-safe, the current solution consists of marking such tests as single threaded, via pytest.mark.parallel_threads(1). By automating this process, libraries could accelerate their free-threading testing, as developers wouldn't have to devote time to find tests that capture warnings and then marking them as single-threaded manually.
This can be done via inspect.getsource and then introspection via ast
As per a discussion over at SciPy https://github.com/scipy/scipy/pull/21496#issuecomment-2468909962, it would be much desirable to devise an introspection mechanism to detect usages of
pytest.warns
and similar constructs that depend on warning interception.Given that the
warnings
module is not thread-safe, the current solution consists of marking such tests as single threaded, viapytest.mark.parallel_threads(1)
. By automating this process, libraries could accelerate their free-threading testing, as developers wouldn't have to devote time to find tests that capture warnings and then marking them as single-threaded manually.This can be done via
inspect.getsource
and then introspection viaast