# PEP 779: Criteria for supported status for free-threaded Python

**URL:** <https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319>\
**Category:** PEPs\
**Created:** [March 13, 2025, 12:25pm UTC](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319 "2025-03-13T12:25:19Z")\
**Posts on this page:** 1\
**Showing post:** 122

<div class="post-metadata">

**Author:** ![oscarbenjamin](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/oscarbenjamin/32/1209_2.png) [@oscarbenjamin](https://discuss.python.org/u/oscarbenjamin)\
**Post date:** [March 24, 2025, 3:57pm UTC](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319/122 "2025-03-24T15:57:02Z")

</div>

> [@csm10495](#):
>
> I guess I’m not really even sure what it means as a package developer myself. I could run my unit tests in a free threaded build, but that doesn’t really test cases with multiple threads since it wasn’t part of the test-plane before. Should it be now?

From my own experience of having done this for a few projects I would say that running the single threaded test suite under the free-threading build is unlikely to surface any issues. What did reveal issues was running the test suite with Quansight’s [pytest-run-parallel](https://github.com/Quansight-Labs/pytest-run-parallel). If you `pip install pytest-run-parallel` then you can run your tests with

```python
pytest --parallel-threads=5 --iterations=10

```

This runs your test suite but runs each test multiple times simultaneously using a thread pool. You can use it with the free-threaded build or with the GIL build. I found that this threw up a lot of false positives but also surfaced what look like a few real issues (although I haven’t looked into them in detail yet). The false positives are that the test suites are not designed for multithreading and mutate global state (e.g. the warnings module filters don’t work with multithreading). The real issues are that I have see a test failure from pure Python code that I assume is something to do with a global cache and I have seen a segfault from a particular extension module under the free threading build.

Using pytest-parallel-threads is a cheap way to test multithreading using your single threaded test suite and probably gives a reasonable first approximation for what it might like if the library is used in a multithreaded program. It does not however stress some of the biggest problems like what happens when objects are shared between threads so for that you probably would need to write some explicit tests. In my case it was fairly obvious that some extension types would potentially crash if mutated by multiple threads but still not trivial to produce a test that stressed this enough to manifest the crash.

Of course having identified any issues you are left with a choice for what to do about them. @ngoldbaum outlined many valid choices. I would say that right now it should be considered reasonable to just document any known issues, say that it is all experimental, and put the package out for others to experiment with. Anyone who uses the free-threaded build with or without your package should understand that they are an early adopter and it is expected that they might run into problems.

---

_[View the full topic](https://discuss.python.org/t/pep-779-criteria-for-supported-status-for-free-threaded-python/84319)._