# PEP 703: Making the Global Interpreter Lock Optional (3.12 updates)

**URL:** <https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503>\
**Category:** PEPs\
**Created:** [May 4, 2023, 6:22pm UTC](https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503 "2023-05-04T18:22:11Z")\
**Posts on this page:** 1\
**Showing post:** 99

<div class="post-metadata">

**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\
**Post date:** [June 12, 2023, 11:56pm UTC](https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/99 "2023-06-12T23:56:30Z")

</div>

> [@jamestwebber](#):
>
> That’s definitely true. But if I’m dependent on a library that’s multi-threaded, surely I have to wait until they release a `nogil` version?

Not necessarily. For instance, will pure Python projects be expected to declare they support free threading?

* * *

@colesbury Speaking of packaging and declaring support, after re-reading the PEP this weekend I assume the expectation is we will have to define an `abi4` or `abi3t` to signal a stable ABI that supports no-GIL (FYI I prefer `t` or `n` to signal “threading” over “no GIL” as an ABI suffix)?

The PEP also mean extension module wheels will double the number of CPython wheels they produce if they want to support both with and without a GIL, correct?

And what’s your suggestion on how to tell if you are running a CPython with or without the GIL? Via `sysconfig` or some other mechanism (i.e., I didn’t see any mention of some change to `sys` to expose this)? Up until this point you could tell e.g. CPython from PyPy by the binary name as well as the feature version, but that isn’t the case here.

---

_[View the full topic](https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503)._
