Repository: Quansight/Quansight-website
Pull request #916: [BLOG] Add 'one year of free-threaded Python' post
Author: login: ngoldbaum
Labels: name: type: content 📝
Created: 2025-05-08T17:10:21Z | Merged: 2025-05-13T19:34:03Z

<!--Hi there! If you aren't submitting a blog post, you can delete this message.
Thank you for submitting a blog post! We want to make sure content produced for Quansight Labs is accessible, so please address the the following guidelines in your post.-->

Add a blog post describing the work from the nogil team over the past year.

Suggestions for header images to go with this are very appreciated, along with review of the text.

## Text styling

- [x] The blog is written with [plain language](https://www.plainlanguage.gov/guidelines/) (where relevant).
- [x] If there are headers, they use the proper header tags in order to do so (with only one level-one header).
- [x] All links describe where they link to (for example, check the [Quansight labs website](https://labs.quansight.org/)).
- [x] Any kind of styling that the author uses (for example, bold for emphasis) is consistent throughout the blog.

## Non-text contents

- [x] Blog post featured image is in PNG or JPEG format, **not** SVG.
- [x] All content is represented as text (for example, images need alt text and videos need captions or descriptive transcripts).
- [x] If there are emojis, there are not more than three in a row.
- [x] Don't use [flashing gifs or videos](https://www.w3.org/TR/UNDERSTANDING-WCAG20/seizure-does-not-violate.html).
- [x] If it were to be read as plain text, the blog still makes sense and no information is missing.



Diff:
diff --git a/apps/labs/posts/free-threaded-one-year-recap.md b/apps/labs/posts/free-threaded-one-year-recap.md
new file mode 100644
index 000000000..3f48a0840
--- /dev/null
+++ b/apps/labs/posts/free-threaded-one-year-recap.md
@@ -0,0 +1,163 @@
+---
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 13, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  alt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+hero:
+  imageSrc: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  imageAlt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+---
+
+Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon
+2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for
+the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at
+Quansight played a key role in enabling experimental use of the free-threaded
+build with real production workflows that depend on a complex set of
+dependencies.
+
+## Introduction: Why are we working on community support for free-threaded Python?
+
+Support for free-threaded Python unlocks the full compute power of modern
+hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled
+build, making full use of parallel algorithms that exploit all available
+compute resources in Python requires workarounds and careful tuning. The Python
+`threading` module is often not used because the GIL prevents useful parallel
+scaling. Instead, many reach for `multiprocessing`, but spawning processes is
+expensive and communicating across processes often requires making expensive
+copies of data that would not be necessary in a multithreaded program where
+data is implicitly shared between threads.
+
+Having said that, it is not possible for packages that ship compiled code in
+their release distributions to support the free-threaded build out of the box.
+Any package shipping native code (many Python packages do that) will need to be
+audited to ensure the package builds and either fix or document the safety
+guarantees provided by the package. Disabling the GIL required deep structural
+changes to the CPython interpreter. Fully supporting the free-threaded build in
+existing packages similarly requires fixing structural issues that until now
+were not big problems. Things like use of global state in the implementation of
+a C extension for convenience or for performance are no longer safe, since the
+GIL does not protect simultaneous access from Python to the global state,
+allowing undefined behavior via data races. While it is possible to trigger
+thread safety issues like this using the `threading` module even with the GIL,
+most of the time the GIL prevented these issues from surfacing. The
+free-threaded build makes fixing these issues much more pressing.
+
+## Major accomplishments
+
+Alongside the Python runtime team at Meta, we made significant contributions to
+enable support for free-threaded Python in a long list of packages and
+projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the
+    setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow,
+    Matplotlib, pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, PyYAML, yarl, multidict,
+    and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support,
+including CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well
+as popular libraries for machine learning workflows like safetensors and
+tokenizers.
+
+CPython core developers on our team also contributed several major improvements
+that will ship in CPython 3.14:
+
+  * The Python `warnings` module is now thread-safe by default on the
+    free-threaded build. It can be made thread-safe on the GIL-enabled build
+    with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in `asyncio` have been fixed. Our
+    benchmarks indicate substantially improved parallel scaling of code using
+    asyncio with a thread pool runner as a function of thread count.
+  * Thread safety overhaul in the `ctypes` module.
+  * Substantial performance improvements for the free-threaded garbage collector.
+  * Helped implement the deferred reference counting scheme used by the
+    free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing
+    interpreter and supported shipping optimizations that bring the
+    single-threaded performance of free-threaded CPython 3.14 within spitting
+    distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io)
+for supporting free-threading in existing apps and packages gleaned from our
+experiences. Our hope is that the documentation we've written can be a valuable
+resource for the "long tail" of packages that people will want to update to
+support free-threaded Python in the coming years.
+
+You can also read more about this effort from the team at Meta on the
+[Meta engineering blog](https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/).
+
+## What is the state of the free-threaded Python ecosystem?
+
+At this time last year, when Python 3.13.0b1 shipped, the wider ecosystem of
+Python packages was more or less completely broken on the free-threaded build.
+Trying to `pip install` anything but the simplest package with no dependencies
+or only pure-Python dependencies would likely lead to build errors. Most of
+these issues were not due to fundamental problems but because of unsupported
+default options or minor assumptions broken on the free-threaded build.
+
+Together with package maintainers and other contributors in the community,
+we have fixed all of these issues and today things are much better. With the
+release of Cython 3.1.0, which ships official support for the free-threaded
+build, we also helped fix one of the most significant source of build issues.
+
+We are currently working on packages that ship compiled code but still do not
+yet ship free-threaded wheels. You can track our progress using our manually
+updated [status tracking table](https://py-free-threading.github.io/tracking/)
+or using Hugo van Kemenade's [automatically updated
+tracker](https://hugovk.github.io/free-threaded-wheels/).
+
+### Challenges
+
+As of today, the free-threaded Python build is ready to experiment with. We
+need more reports of bad performance and bugs from people with real-world
+workflows. Significant performance improvements are possible, particularly in
+workflows that make use of multiprocessing and are paying the costs inherent to
+that approach. However, many packages still need detailed auditing to discover
+thread safety issues. Many Python libraries ship mutable data structures that
+will not behave correctly under shared mutating and with no or minimal
+documentation on thread safety or multithreaded performance.
+
+As in any change of this magnitude that affects an entire programming language
+package ecosystem, we are hitting cases where popular packages do not have the
+resources needed to deal with changes needed to support free-threading. This is
+particularly true of large legacy packages where few people or even no one
+fully understands the code. As a community, we need to understand these issues
+in our dependency trees and work towards sustainable maintenance for critical
+packages.
+
+### How can you help?
+
+Take a look at the [contribution guide](https://py-free-threading.github.io/contributing/)
+we've added to the main free-threading guide. We're tracking ecosystem-wide
+issues and writing the content of the free-threaded guide in the
+[free-threaded-compatibility](https://github.com/Quansight-Labs/free-threaded-compatibility)
+repository hosted on the Quansight-Labs GitHub org.
+
+We also helped launch a [community Discord](https://discord.gg/rqgHCDqdRr) to host
+discussions about supporting the free-threaded build. Come join us if you're
+interested in helping out!
+
+## Come to our talk at PyCon!
+
+I will be giving [a talk at
+PyCon](https://us.pycon.org/2025/schedule/presentation/42/) with my teammate
+[Lysandros Nikolaou](https://github.com/lysnikolaou). If you'll be attending
+the conference, please come and watch. We'll be sharing details from our
+experiences porting packages to support the free-threaded build. We're hopeful
+that the recording on YouTube will be a lasting valuable resource for the
+visual learners of the world.
+
+Personally, I believe the free-threaded build is the future of the language,
+and am excited that I get to work full-time on enabling that. I'm also hopeful
+that the work we're doing now will enable future work in the long tail of
+packages used every day by millions of developers and dramatically improve the
+performance of the language.
diff --git a/apps/labs/public/posts/free-threaded-one-year-recap/snake-cartoon.jpg b/apps/labs/public/posts/free-threaded-one-year-recap/snake-cartoon.jpg
new file mode 100644
index 000000000..60576873d
Binary files /dev/null and b/apps/labs/public/posts/free-threaded-one-year-recap/snake-cartoon.jpg differ


Reviews:
user: login: ngoldbaum
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-08T17:14:48Z
user: login: kumaraditya303
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-08T17:33:37Z
user: login: lysnikolaou
body: Thanks @ngoldbaum! Looks good! I left some comments inline.

Also, one "bigger" suggestion: Could we may be more succinct in describing what free-threaded Python is? There's loads of resources on that everywhere and I'm not sure we should be iterating that here. I think it'd be best if we only provided a very very high-level overview (effectively before: GIL was protecting us, now: it isn't) and then link to one of those resources, maybe even @rgommers's blog post from last year.
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-09T09:37:29Z
user: login: gabalafou
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-09T15:38:13Z
user: login: lysnikolaou
body: Α few more suggestions from a second read and I think it's good to go.
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-12T19:51:30Z
user: login: lysnikolaou
body: Good to go on my end!
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-05-13T07:00:17Z
user: login: kumaraditya303
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-05-13T08:08:31Z
user: login: rgommers
body: Thanks @ngoldbaum & all reviewers! This looks about ready to go. I pushed some minor editorial edits, and there's one larger thing that deserves some attention: it's important to not claim too much of the credit and say "we have ...." unless it was actually us. I made two suggested edits that should address this. I think we've done something like 50% of all the heavy lifting over the past year on widely used OSS packages, so let's recognize that other half.
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-13T08:43:35Z
user: login: rgommers
body: Great, in it goes - should be live in 5 minutes or so!
state: APPROVED
author_association: MEMBER
submitted_at: 2025-05-13T19:33:44Z

Review comments:
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+
+## Major accomplishments
+
+With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a laundry list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenziers.
+
+CPython core developers on our team also contributed several major improvements that will be shipped in CPython 3.14:
+
+  * The Python warnings module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in asyncio have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * Helped implement and ship the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing interpreter and supported shipping optimizations that bring the single-threaded performance of free-threaded CPython 3.14 within spitting distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io) for supporting free-threaded in existing apps and packages gleaned from our experiences. Our hope is that the documentation we've written can be a valuable resource for the "long tail" of packakes that people will want to update to support free-threaded Python in the coming years.
+
+## What is the state of the free-threaded Python ecosystem?
+
+At this time last year, when Python 3.13.0b1 shipped, the wider ecosystem of Python packages was more or less completely broken on the free-threaded build. Trying to `pip install` anything but the simplest package with no dependencies or only pure-Python dependencies would likely lead to build errors. Most of these issues were not due to fundamental problems but because of unsupported default options or minor assumptions broken on the free-threaded build.
+
+We have fixed all of these issues and today things are much better. With the immenent release of Cython 3.1.0, which will ship official support for the free-threaded build, we will also soon fix one of the most significant source of build issues.
+
+We are currently working on packages that ship compiled code but still do not yet ship free-threaded wheels. You can track our progress using our manually updated [status tracking table](https://py-free-threading.github.io/tracking/) or using Hugo van Kemenade's [automatically updated tracker](https://hugovk.github.io/free-threaded-wheels/).
+
+### Challenges
+
+As of today, the free-threaded Python build is ready to experiment with. We need more reports of bad performance and bugs from people with real-world workflows. Significant performance improvements are possible, particularly in workflows that make use of multiprocessing and are paying the costs inherent to that approach. However, many packages still need detailed auditing to discover thread safety issues. Many Python libraries ship mutable data structures that will not behave correctly under shared mutating and with no or minimal documentation on thread safety or multithreaded performance.
+
+As in any change of this magnitude that effects an entire programming language package ecosystem, we are hitting cases where popular packages do not have the resources needed to deal with changes needed to support free-threading. This is particularly true of large legacy packages where few people or even no one fully understands the code. As a community, we need to understand these issues in our dependency trees and work towards sustainable maintenance for critical packages.
+
+### How can you help?
+
+Take a look at the [contribution guide](https://py-free-threading.github.io/contributing/) we've added to the main free-threading guide. We're tracking ecosystem-wide issues and writing the content of the free-threaded guide in the [free-threaded-compatibility](https://github.com/Quansight-Labs/free-threaded-compatibility) repository hosted on the Quansight-Labs GitHub org.
+
+We also launched a [community Discord](https://discord.gg/rqgHCDqdRr) to host discussions about supporting the free-threaded build. Come join us if you're interested in helping out!
+
+## Come to our talk at PyCon!
+
+I will be giving a talk at PyCon with my teammate [Lysandros Nikolaou](https://github.com/lysnikolaou). If you'll be attending the conference, please come and watch. We'll be sharing details from our experiences porting packages to support the free-threaded build. We're hopeful that the recording on YouTube will be a lasting valuable resource for the visual learners of the world.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: ngoldbaum
body: should add a link to the abstract
created_at: 2025-05-08T17:14:48Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+
+## Major accomplishments
+
+With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a laundry list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenziers.
+
+CPython core developers on our team also contributed several major improvements that will be shipped in CPython 3.14:
+
+  * The Python warnings module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in asyncio have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: kumaraditya303
body: maybe mention that thread safety issues of ctypes is also fixed now
created_at: 2025-05-08T17:33:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: These will have to be adjusted.
created_at: 2025-05-09T09:07:32Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
```
created_at: 2025-05-09T09:08:34Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
This is the story of the first year of that effort and how our team at Quansight played a key role in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
```
created_at: 2025-05-09T09:08:57Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the Global Interpreter Lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and the GIL is disabled by default. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
```
created_at: 2025-05-09T09:09:45Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resources in Python requires workarounds and careful tuning. The Python `threading` module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for `multiprocessing`, but spawning processes is expensive and communicating across processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
```
created_at: 2025-05-09T09:11:36Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: I don't think it sounds like a small implementation detail to many people. Most of the community knows how big the change is and how much of an ongoing effort has been in the past to do that.

```suggestion
Disabling the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the `threading` module, even with the GIL, most of the time the GIL prevented these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
```
created_at: 2025-05-09T09:20:51Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
```
created_at: 2025-05-09T09:21:11Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+
+## Major accomplishments
+
+With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a laundry list of packages and projects, including:
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: I had to search what "laundry list" exactly means in this context. 😆 Maybe just use "long list" for non-native English speakers?

```suggestion
With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a long list of packages and projects, including:
```
created_at: 2025-05-09T09:22:58Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+
+## Major accomplishments
+
+With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a laundry list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenziers.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: Let's move `PyYAML` to the top dependencies by PyPI downloads above?

Also, typo:

```suggestion
We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenizers.
```
created_at: 2025-05-09T09:25:38Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+
+## Major accomplishments
+
+With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a laundry list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenziers.
+
+CPython core developers on our team also contributed several major improvements that will be shipped in CPython 3.14:
+
+  * The Python warnings module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in asyncio have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * Helped implement and ship the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing interpreter and supported shipping optimizations that bring the single-threaded performance of free-threaded CPython 3.14 within spitting distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io) for supporting free-threaded in existing apps and packages gleaned from our experiences. Our hope is that the documentation we've written can be a valuable resource for the "long tail" of packakes that people will want to update to support free-threaded Python in the coming years.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
We've also written a [comprehensive guide](https://py-free-threading.github.io) for supporting free-threading in existing apps and packages gleaned from our experiences. Our hope is that the documentation we've written can be a valuable resource for the "long tail" of packakes that people will want to update to support free-threaded Python in the coming years.
```
created_at: 2025-05-09T09:27:40Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+
+## Major accomplishments
+
+With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a laundry list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenziers.
+
+CPython core developers on our team also contributed several major improvements that will be shipped in CPython 3.14:
+
+  * The Python warnings module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in asyncio have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * Helped implement and ship the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing interpreter and supported shipping optimizations that bring the single-threaded performance of free-threaded CPython 3.14 within spitting distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io) for supporting free-threaded in existing apps and packages gleaned from our experiences. Our hope is that the documentation we've written can be a valuable resource for the "long tail" of packakes that people will want to update to support free-threaded Python in the coming years.
+
+## What is the state of the free-threaded Python ecosystem?
+
+At this time last year, when Python 3.13.0b1 shipped, the wider ecosystem of Python packages was more or less completely broken on the free-threaded build. Trying to `pip install` anything but the simplest package with no dependencies or only pure-Python dependencies would likely lead to build errors. Most of these issues were not due to fundamental problems but because of unsupported default options or minor assumptions broken on the free-threaded build.
+
+We have fixed all of these issues and today things are much better. With the immenent release of Cython 3.1.0, which will ship official support for the free-threaded build, we will also soon fix one of the most significant source of build issues.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: Not imminent anymore! 🎉 

```suggestion
We have fixed all of these issues and today things are much better. With the release of Cython 3.1.0, which ships official support for the free-threaded build, we also have fixed one of the most significant source of build issues.
```
created_at: 2025-05-09T09:28:51Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/hello-world-post/featured.png
+  alt: 'Excellent alt-text describing the featured image'
+hero:
+  imageSrc: /posts/hello-world-post/hero.jpeg
+  imageAlt: 'Excellent alt-text describing the hero image'
+---
+
+Last week, the Python developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key roll in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: What is free-threaded Python and why are we working on it?
+
+Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the global interpreter lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and there is no GIL. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+
+The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resource in Python requires workarounds and careful tuning. The Python threading module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for multiprocessing, but spawning processes is expensive and communicating with processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+While it may sound like a small implementation detail, "simply" removing the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues with many packages that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the threading module, even with the GIL, most of the time the GIL prevents these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (any many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+
+## Major accomplishments
+
+With assistance from the team at Meta driving free-threaded support there and in the wider community we made significant contributions to enable support for free-threaded Python in a laundry list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenziers.
+
+CPython core developers on our team also contributed several major improvements that will be shipped in CPython 3.14:
+
+  * The Python warnings module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in asyncio have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * Helped implement and ship the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing interpreter and supported shipping optimizations that bring the single-threaded performance of free-threaded CPython 3.14 within spitting distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io) for supporting free-threaded in existing apps and packages gleaned from our experiences. Our hope is that the documentation we've written can be a valuable resource for the "long tail" of packakes that people will want to update to support free-threaded Python in the coming years.
+
+## What is the state of the free-threaded Python ecosystem?
+
+At this time last year, when Python 3.13.0b1 shipped, the wider ecosystem of Python packages was more or less completely broken on the free-threaded build. Trying to `pip install` anything but the simplest package with no dependencies or only pure-Python dependencies would likely lead to build errors. Most of these issues were not due to fundamental problems but because of unsupported default options or minor assumptions broken on the free-threaded build.
+
+We have fixed all of these issues and today things are much better. With the immenent release of Cython 3.1.0, which will ship official support for the free-threaded build, we will also soon fix one of the most significant source of build issues.
+
+We are currently working on packages that ship compiled code but still do not yet ship free-threaded wheels. You can track our progress using our manually updated [status tracking table](https://py-free-threading.github.io/tracking/) or using Hugo van Kemenade's [automatically updated tracker](https://hugovk.github.io/free-threaded-wheels/).
+
+### Challenges
+
+As of today, the free-threaded Python build is ready to experiment with. We need more reports of bad performance and bugs from people with real-world workflows. Significant performance improvements are possible, particularly in workflows that make use of multiprocessing and are paying the costs inherent to that approach. However, many packages still need detailed auditing to discover thread safety issues. Many Python libraries ship mutable data structures that will not behave correctly under shared mutating and with no or minimal documentation on thread safety or multithreaded performance.
+
+As in any change of this magnitude that effects an entire programming language package ecosystem, we are hitting cases where popular packages do not have the resources needed to deal with changes needed to support free-threading. This is particularly true of large legacy packages where few people or even no one fully understands the code. As a community, we need to understand these issues in our dependency trees and work towards sustainable maintenance for critical packages.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
As in any change of this magnitude that affects an entire programming language package ecosystem, we are hitting cases where popular packages do not have the resources needed to deal with changes needed to support free-threading. This is particularly true of large legacy packages where few people or even no one fully understands the code. As a community, we need to understand these issues in our dependency trees and work towards sustainable maintenance for critical packages.
```
created_at: 2025-05-09T09:31:17Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+```
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: gabalafou
body: ```suggestion
---
```

I think that may be why the build for this PR is failing
created_at: 2025-05-09T15:38:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,74 @@
+---
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  alt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+hero:
+  imageSrc: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  imageAlt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+---
+
+Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key role in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: Why are we working on community support for free-threaded Python?
+
+Support for free-threaded Python unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resources in Python requires workarounds and careful tuning. The Python `threading` module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for `multiprocessing`, but spawning processes is expensive and communicating across processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+We need to work to add add support for free-threaded Python because it is not possible for packages that ship compiled code in their release distributions to "automatically" support the free-threaded build. Any package shipping native code (many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package. Disabling the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the `threading` module, even with the GIL, most of the time the GIL prevented these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: Minor suggestion for a smoother transition to the "why".

```suggestion
Having said that, it is not possible for packages that ship compiled code in their release distributions to support the free-threaded build out of the box. Any package shipping native code (many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package. Disabling the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the `threading` module, even with the GIL, most of the time the GIL prevented these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
```
created_at: 2025-05-12T19:27:10Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+---
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  alt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+hero:
+  imageSrc: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  imageAlt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+---
+
+Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key role in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: Why are we working on community support for free-threaded Python?
+
+Support for free-threaded Python unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resources in Python requires workarounds and careful tuning. The Python `threading` module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for `multiprocessing`, but spawning processes is expensive and communicating across processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+We need to work to add add support for free-threaded Python because it is not possible for packages that ship compiled code in their release distributions to "automatically" support the free-threaded build. Any package shipping native code (many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package. Disabling the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the `threading` module, even with the GIL, most of the time the GIL prevented these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+## Major accomplishments
+
+Alongside the Python runtime team at Meta, we made significant contributions to enable support for free-threaded Python in a long list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, PyYAML, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenizers.
+
+CPython core developers on our team also contributed several major improvements that will ship in CPython 3.14:
+
+  * The Python `warnings` module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in `asyncio` have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * Thread safety overhaul in the `ctypes` module.
+  * Substantial performance improvements for the free-threaded garbage collector.
+  * Helped implement and ship the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
  * Helped implement the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
```
created_at: 2025-05-12T19:32:01Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,74 @@
+---
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 12, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  alt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+hero:
+  imageSrc: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  imageAlt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+---
+
+Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at Quansight played a key role in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
+
+## Introduction: Why are we working on community support for free-threaded Python?
+
+Support for free-threaded Python unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resources in Python requires workarounds and careful tuning. The Python `threading` module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for `multiprocessing`, but spawning processes is expensive and communicating across processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
+
+We need to work to add add support for free-threaded Python because it is not possible for packages that ship compiled code in their release distributions to "automatically" support the free-threaded build. Any package shipping native code (many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package. Disabling the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the `threading` module, even with the GIL, most of the time the GIL prevented these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
+
+## Major accomplishments
+
+Alongside the Python runtime team at Meta, we made significant contributions to enable support for free-threaded Python in a long list of packages and projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, PyYAML, yarl, multidict, and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support, including CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenizers.
+
+CPython core developers on our team also contributed several major improvements that will ship in CPython 3.14:
+
+  * The Python `warnings` module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in `asyncio` have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * Thread safety overhaul in the `ctypes` module.
+  * Substantial performance improvements for the free-threaded garbage collector.
+  * Helped implement and ship the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing interpreter and supported shipping optimizations that bring the single-threaded performance of free-threaded CPython 3.14 within spitting distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io) for supporting free-threading in existing apps and packages gleaned from our experiences. Our hope is that the documentation we've written can be a valuable resource for the "long tail" of packakes that people will want to update to support free-threaded Python in the coming years.
+
+You can read more about this effort from the team at Meta on the [Meta engineering blog](https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/).
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: lysnikolaou
body: ```suggestion
You can also read more about this effort from the team at Meta on the [Meta engineering blog](https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/).
```
created_at: 2025-05-12T19:32:43Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,162 @@
+---
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 13, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  alt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+hero:
+  imageSrc: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  imageAlt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+---
+
+Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon
+2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for
+the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at
+Quansight played a key role in enabling experimental use of the free-threaded
+build with real production workflows that depend on a complex set of
+dependencies.
+
+## Introduction: Why are we working on community support for free-threaded Python?
+
+Support for free-threaded Python unlocks the full compute power of modern
+hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled
+build, making full use of parallel algorithms that exploit all available
+compute resources in Python requires workarounds and careful tuning. The Python
+`threading` module is often not used because the GIL prevents useful parallel
+scaling. Instead, many reach for `multiprocessing`, but spawning processes is
+expensive and communicating across processes often requires making expensive
+copies of data that would not be necessary in a multithreaded program where
+data is implicitly shared between threads.
+
+Having said that, it is not possible for packages that ship compiled code in
+their release distributions to support the free-threaded build out of the box.
+Any package shipping native code (many Python packages do that) will need to be
+audited to ensure the package builds and either fix or document the safety
+guarantees provided by the package. Disabling the GIL required deep structural
+changes to the CPython interpreter. Fully supporting the free-threaded build in
+existing packages similarly requires fixing structural issues that until now
+were not big problems. Things like use of global state in the implementation of
+a C extension for convenience or for performance are no longer safe, since the
+GIL does not protect simultaneous access from Python to the global state,
+allowing undefined behavior via data races. While it is possible to trigger
+thread safety issues like this using the `threading` module even with the GIL,
+most of the time the GIL prevented these issues from surfacing. The
+free-threaded build makes fixing these issues much more pressing.
+
+## Major accomplishments
+
+Alongside the Python runtime team at Meta, we made significant contributions to
+enable support for free-threaded Python in a long list of packages and
+projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the
+    setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow,
+    Matplotlib, pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, PyYAML, yarl, multidict,
+    and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support,
+including CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well
+as popular libraries for machine learning workflows like safetensors and
+tokenizers.
+
+CPython core developers on our team also contributed several major improvements
+that will ship in CPython 3.14:
+
+  * The Python `warnings` module is now thread-safe by default on the
+    free-threaded build. It can be made thread-safe on the GIL-enabled build
+    with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in `asyncio` have been fixed. Our
+    benchmarks indicate substantially improved parallel scaling of code using
+    asyncio with a thread pool runner as a function of thread count.
+  * Thread safety overhaul in the `ctypes` module.
+  * Substantial performance improvements for the free-threaded garbage collector.
+  * Helped implement the deferred reference counting scheme used by the
+    free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing
+    interpreter and supported shipping optimizations that bring the
+    single-threaded performance of free-threaded CPython 3.14 within spitting
+    distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io)
+for supporting free-threading in existing apps and packages gleaned from our
+experiences. Our hope is that the documentation we've written can be a valuable
+resource for the "long tail" of packages that people will want to update to
+support free-threaded Python in the coming years.
+
+You can also read more about this effort from the team at Meta on the
+[Meta engineering blog](https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/).
+
+## What is the state of the free-threaded Python ecosystem?
+
+At this time last year, when Python 3.13.0b1 shipped, the wider ecosystem of
+Python packages was more or less completely broken on the free-threaded build.
+Trying to `pip install` anything but the simplest package with no dependencies
+or only pure-Python dependencies would likely lead to build errors. Most of
+these issues were not due to fundamental problems but because of unsupported
+default options or minor assumptions broken on the free-threaded build.
+
+We have fixed all of these issues and today things are much better. With the
+release of Cython 3.1.0, which ships official support for the free-threaded
+build, we also have fixed one of the most significant source of build issues.
+
+We are currently working on packages that ship compiled code but still do not
+yet ship free-threaded wheels. You can track our progress using our manually
+updated [status tracking table](https://py-free-threading.github.io/tracking/)
+or using Hugo van Kemenade's [automatically updated
+tracker](https://hugovk.github.io/free-threaded-wheels/).
+
+### Challenges
+
+As of today, the free-threaded Python build is ready to experiment with. We
+need more reports of bad performance and bugs from people with real-world
+workflows. Significant performance improvements are possible, particularly in
+workflows that make use of multiprocessing and are paying the costs inherent to
+that approach. However, many packages still need detailed auditing to discover
+thread safety issues. Many Python libraries ship mutable data structures that
+will not behave correctly under shared mutating and with no or minimal
+documentation on thread safety or multithreaded performance.
+
+As in any change of this magnitude that affects an entire programming language
+package ecosystem, we are hitting cases where popular packages do not have the
+resources needed to deal with changes needed to support free-threading. This is
+particularly true of large legacy packages where few people or even no one
+fully understands the code. As a community, we need to understand these issues
+in our dependency trees and work towards sustainable maintenance for critical
+packages.
+
+### How can you help?
+
+Take a look at the [contribution guide](https://py-free-threading.github.io/contributing/)
+we've added to the main free-threading guide. We're tracking ecosystem-wide
+issues and writing the content of the free-threaded guide in the
+[free-threaded-compatibility](https://github.com/Quansight-Labs/free-threaded-compatibility)
+repository hosted on the Quansight-Labs GitHub org.
+
+We also launched a [community Discord](https://discord.gg/rqgHCDqdRr) to host
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: rgommers
body: ```suggestion
We also helped launch a [community Discord](https://discord.gg/rqgHCDqdRr) to host
```
created_at: 2025-05-13T08:38:10Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,162 @@
+---
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 13, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  alt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+hero:
+  imageSrc: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  imageAlt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+---
+
+Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon
+2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for
+the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at
+Quansight played a key role in enabling experimental use of the free-threaded
+build with real production workflows that depend on a complex set of
+dependencies.
+
+## Introduction: Why are we working on community support for free-threaded Python?
+
+Support for free-threaded Python unlocks the full compute power of modern
+hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled
+build, making full use of parallel algorithms that exploit all available
+compute resources in Python requires workarounds and careful tuning. The Python
+`threading` module is often not used because the GIL prevents useful parallel
+scaling. Instead, many reach for `multiprocessing`, but spawning processes is
+expensive and communicating across processes often requires making expensive
+copies of data that would not be necessary in a multithreaded program where
+data is implicitly shared between threads.
+
+Having said that, it is not possible for packages that ship compiled code in
+their release distributions to support the free-threaded build out of the box.
+Any package shipping native code (many Python packages do that) will need to be
+audited to ensure the package builds and either fix or document the safety
+guarantees provided by the package. Disabling the GIL required deep structural
+changes to the CPython interpreter. Fully supporting the free-threaded build in
+existing packages similarly requires fixing structural issues that until now
+were not big problems. Things like use of global state in the implementation of
+a C extension for convenience or for performance are no longer safe, since the
+GIL does not protect simultaneous access from Python to the global state,
+allowing undefined behavior via data races. While it is possible to trigger
+thread safety issues like this using the `threading` module even with the GIL,
+most of the time the GIL prevented these issues from surfacing. The
+free-threaded build makes fixing these issues much more pressing.
+
+## Major accomplishments
+
+Alongside the Python runtime team at Meta, we made significant contributions to
+enable support for free-threaded Python in a long list of packages and
+projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the
+    setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow,
+    Matplotlib, pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, PyYAML, yarl, multidict,
+    and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support,
+including CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well
+as popular libraries for machine learning workflows like safetensors and
+tokenizers.
+
+CPython core developers on our team also contributed several major improvements
+that will ship in CPython 3.14:
+
+  * The Python `warnings` module is now thread-safe by default on the
+    free-threaded build. It can be made thread-safe on the GIL-enabled build
+    with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in `asyncio` have been fixed. Our
+    benchmarks indicate substantially improved parallel scaling of code using
+    asyncio with a thread pool runner as a function of thread count.
+  * Thread safety overhaul in the `ctypes` module.
+  * Substantial performance improvements for the free-threaded garbage collector.
+  * Helped implement the deferred reference counting scheme used by the
+    free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing
+    interpreter and supported shipping optimizations that bring the
+    single-threaded performance of free-threaded CPython 3.14 within spitting
+    distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io)
+for supporting free-threading in existing apps and packages gleaned from our
+experiences. Our hope is that the documentation we've written can be a valuable
+resource for the "long tail" of packages that people will want to update to
+support free-threaded Python in the coming years.
+
+You can also read more about this effort from the team at Meta on the
+[Meta engineering blog](https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/).
+
+## What is the state of the free-threaded Python ecosystem?
+
+At this time last year, when Python 3.13.0b1 shipped, the wider ecosystem of
+Python packages was more or less completely broken on the free-threaded build.
+Trying to `pip install` anything but the simplest package with no dependencies
+or only pure-Python dependencies would likely lead to build errors. Most of
+these issues were not due to fundamental problems but because of unsupported
+default options or minor assumptions broken on the free-threaded build.
+
+We have fixed all of these issues and today things are much better. With the
+release of Cython 3.1.0, which ships official support for the free-threaded
+build, we also have fixed one of the most significant source of build issues.
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: rgommers
body: ```suggestion
build, we also helped fix one of the most significant source of build issues.
```
created_at: 2025-05-13T08:38:49Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,162 @@
+---
+title: 'The first year of free-threaded Python'
+authors: [nathan-goldbaum]
+published: May 13, 2025
+description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
+category: [Community, PyData ecosystem]
+featuredImage:
+  src: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  alt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+hero:
+  imageSrc: /posts/free-threaded-one-year-recap/snake-cartoon.jpg
+  imageAlt: 'A cartoon of a Python wrapped around a thread, illustrating Python and threads getting along.'
+---
+
+Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon
+2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for
+the effort to ship and stabilize free-threaded Python.
+
+This is the story of the first year of that effort and how our team at
+Quansight played a key role in enabling experimental use of the free-threaded
+build with real production workflows that depend on a complex set of
+dependencies.
+
+## Introduction: Why are we working on community support for free-threaded Python?
+
+Support for free-threaded Python unlocks the full compute power of modern
+hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled
+build, making full use of parallel algorithms that exploit all available
+compute resources in Python requires workarounds and careful tuning. The Python
+`threading` module is often not used because the GIL prevents useful parallel
+scaling. Instead, many reach for `multiprocessing`, but spawning processes is
+expensive and communicating across processes often requires making expensive
+copies of data that would not be necessary in a multithreaded program where
+data is implicitly shared between threads.
+
+Having said that, it is not possible for packages that ship compiled code in
+their release distributions to support the free-threaded build out of the box.
+Any package shipping native code (many Python packages do that) will need to be
+audited to ensure the package builds and either fix or document the safety
+guarantees provided by the package. Disabling the GIL required deep structural
+changes to the CPython interpreter. Fully supporting the free-threaded build in
+existing packages similarly requires fixing structural issues that until now
+were not big problems. Things like use of global state in the implementation of
+a C extension for convenience or for performance are no longer safe, since the
+GIL does not protect simultaneous access from Python to the global state,
+allowing undefined behavior via data races. While it is possible to trigger
+thread safety issues like this using the `threading` module even with the GIL,
+most of the time the GIL prevented these issues from surfacing. The
+free-threaded build makes fixing these issues much more pressing.
+
+## Major accomplishments
+
+Alongside the Python runtime team at Meta, we made significant contributions to
+enable support for free-threaded Python in a long list of packages and
+projects, including:
+
+  * Packaging and project workflow tools like meson, meson-python, the
+    setup-python GitHub workflow, packaging, pip, and setuptools.
+  * Bindings generators like Cython, pybind11, f2py, and PyO3.
+  * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow,
+    Matplotlib, pandas, scikit-learn, and scikit-image.
+  * Top dependencies by PyPI downloads like Pillow, PyYAML, yarl, multidict,
+    and frozenlist.
+
+We are also currently looking at popular packages that don't yet ship support,
+including CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well
+as popular libraries for machine learning workflows like safetensors and
+tokenizers.
+
+CPython core developers on our team also contributed several major improvements
+that will ship in CPython 3.14:
+
+  * The Python `warnings` module is now thread-safe by default on the
+    free-threaded build. It can be made thread-safe on the GIL-enabled build
+    with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in `asyncio` have been fixed. Our
+    benchmarks indicate substantially improved parallel scaling of code using
+    asyncio with a thread pool runner as a function of thread count.
+  * Thread safety overhaul in the `ctypes` module.
+  * Substantial performance improvements for the free-threaded garbage collector.
+  * Helped implement the deferred reference counting scheme used by the
+    free-threaded interpreter in 3.14.
+  * Implemented several specializations for the adaptive specializing
+    interpreter and supported shipping optimizations that bring the
+    single-threaded performance of free-threaded CPython 3.14 within spitting
+    distance of the GIL-enabled build.
+  * A huge number of smaller bugfixes and thread safety improvements.
+
+We've also written a [comprehensive guide](https://py-free-threading.github.io)
+for supporting free-threading in existing apps and packages gleaned from our
+experiences. Our hope is that the documentation we've written can be a valuable
+resource for the "long tail" of packages that people will want to update to
+support free-threaded Python in the coming years.
+
+You can also read more about this effort from the team at Meta on the
+[Meta engineering blog](https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/).
+
+## What is the state of the free-threaded Python ecosystem?
+
+At this time last year, when Python 3.13.0b1 shipped, the wider ecosystem of
+Python packages was more or less completely broken on the free-threaded build.
+Trying to `pip install` anything but the simplest package with no dependencies
+or only pure-Python dependencies would likely lead to build errors. Most of
+these issues were not due to fundamental problems but because of unsupported
+default options or minor assumptions broken on the free-threaded build.
+
+We have fixed all of these issues and today things are much better. With the
path: apps/labs/posts/free-threaded-one-year-recap.md
user: login: rgommers
body: ```suggestion
Together with package maintainers and other contributors in the community,
we have fixed all of these issues and today things are much better. With the
```
created_at: 2025-05-13T08:40:41Z
author_association: MEMBER

PR comments:
user: login: vercel[bot]
created_at: 2025-05-08T17:10:25Z
body: [vc]: #24nvac7Db0v8RZHU7EbvGAt/z1K1yUY3vdOcypqtCLg=:eyJpc01vbm9yZXBvIjp0cnVlLCJ0eXBlIjoiZ2l0aHViIiwicHJvamVjdHMiOlt7Im5hbWUiOiJsYWJzIiwicm9vdERpcmVjdG9yeSI6bnVsbCwiaW5zcGVjdG9yVXJsIjoiaHR0cHM6Ly92ZXJjZWwuY29tL3F1YW5zaWdodC9sYWJzLzNIc3NVcjV0dURhSk5QaHFSQUEzWTRYMlJWRjgiLCJwcmV2aWV3VXJsIjoibGFicy1naXQtZm9yay1uZ29sZGJhdW0tZnJlZS10aHJlYWRlZC1wb3N0LXF1YW5zaWdodC52ZXJjZWwuYXBwIiwibmV4dENvbW1pdFN0YXR1cyI6IkRFUExPWUVEIiwibGl2ZUZlZWRiYWNrIjp7InJlc29sdmVkIjowLCJ1bnJlc29sdmVkIjowLCJ0b3RhbCI6MCwibGluayI6ImxhYnMtZ2l0LWZvcmstbmdvbGRiYXVtLWZyZWUtdGhyZWFkZWQtcG9zdC1xdWFuc2lnaHQudmVyY2VsLmFwcCJ9fV19
**The latest updates on your projects**. Learn more about [Vercel for Git ↗︎](https://vercel.link/github-learn-more)

| Name | Status | Preview | Comments | Updated (UTC) |
| :--- | :----- | :------ | :------- | :------ |
| **labs** | ✅ Ready ([Inspect](https://vercel.com/quansight/labs/3HssUr5tuDaJNPhqRAA3Y4X2RVF8)) | [Visit Preview](https://labs-git-fork-ngoldbaum-free-threaded-post-quansight.vercel.app) | 💬 [**Add feedback**](https://vercel.live/open-feedback/labs-git-fork-ngoldbaum-free-threaded-post-quansight.vercel.app?via=pr-comment-feedback-link) | May 13, 2025 3:31pm |


author_association: NONE
user: login: nascheme
created_at: 2025-05-08T21:12:04Z
body: The performance optimizations to the free-threaded GC are noteworthy, IMHO.   The free-threaded build uses it's own cyclic GC implementation.  I added two optimizations to the collection process in 3.14: mark-alive pass and pre-fetching (used only within mark-alive pass).  

Times below are from my "gc_big_tree.py" benchmark.  The performance benefit  will depend on the workload and this benchmark is kind of a best case scenario (large and complex object graph, causing traversal to visit many scattered locations in memory).

| config     | create time [ms] | collect time [ms] | speedup |
| ---------- | ---------------- | ----------------- | ------- |
| base       | 32,178           | 897               |         |
| mark-alive | 30,886           | 488               | 1.8     |
| pre-fetch  | 30,983           | 365               | 2.5     |

It was a small piece of code but the deferring of full collections also can give a significant speedup.  On the toy list append benchmark in the issue, it makes it run 10 times faster (0.2 seconds vs 2 seconds).

https://github.com/python/cpython/pull/133399
author_association: CONTRIBUTOR
user: login: ngoldbaum
created_at: 2025-05-09T18:57:58Z
body: I threw in an image from the talk but I don't think it looks very good in the blog. Would very much appreciate alternate suggestions for graphics.
author_association: CONTRIBUTOR
user: login: kumaraditya303
created_at: 2025-05-10T09:26:14Z
body: > I threw in an image from the talk but I don't think it looks very good in the blog. Would very much appreciate alternate suggestions for graphics.

How about adding one of graphs I posted about scaling asyncio across threads? The blogpost mentions scaling of asyncio so adding that would be good to have.
author_association: CONTRIBUTOR
user: login: ngoldbaum
created_at: 2025-05-12T17:55:00Z
body: > How about adding one of graphs I posted about scaling asyncio across threads? The blogpost mentions scaling of asyncio so adding that would be good to have.

Thanks for the suggestion. I ended up going with a bit of AI-generated art - I felt like having graphs at the top of the post would distract a bit. We should highlight your work on asyncio in its own blog post IMO.
author_association: CONTRIBUTOR
user: login: ngoldbaum
created_at: 2025-05-13T15:24:53Z
body: Done, thanks for the dose of humility!
author_association: CONTRIBUTOR