# A fast, free threading Python **URL:** \ **Category:** Ideas\ **Created:** [June 15, 2023, 3:28pm UTC](https://discuss.python.org/t/a-fast-free-threading-python/27903 "2023-06-15T15:28:04Z")\ **Posts on this page:** 5\ **Page:** 8
**Author:** ![negatron](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/negatron/32/10623_2.png) [@negatron](https://discuss.python.org/u/negatron)\ **Post date:** [July 12, 2023, 4:44pm UTC](https://discuss.python.org/t/a-fast-free-threading-python/27903/144 "2023-07-12T16:44:09Z")
Honestly, it seems to me you are asking to promote the GIL as a feature of CPython instead of an implementation detail. If this is the case then should be documented, because IMHO it’s impossible to have free-threading and the GIL in the same time. ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [July 12, 2023, 6:15pm UTC](https://discuss.python.org/t/a-fast-free-threading-python/27903/145 "2023-07-12T18:15:15Z")
(Moderator can you do something to slow down this thread?) ---
**Author:** ![Kwpolska](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/kwpolska/32/10542_2.png) [@Kwpolska](https://discuss.python.org/u/Kwpolska)\ **Post date:** [July 12, 2023, 7:22pm UTC](https://discuss.python.org/t/a-fast-free-threading-python/27903/146 "2023-07-12T19:22:47Z")
> [@lieryan](#): > > 1. there’s no full nogil implementation yet, so it’s not really fair to point out specific implementation flaws The [reference implementations on top of 3.9 and 3.12](https://peps.python.org/pep-0703/#reference-implementation) exist, and many discussions (especially those involving benchmarks) are based on those. There are some missing things, as the PEP says, but it is a valid and working implementation. > [@lieryan](#): > > 1. either dumb down free threading so everything would be safe enough by having enough locks (and you still have the issue with native libraries which won’t always be written by people who are experienced with writing multithreaded native code, much less multithreaded nogil CPython extension, so in practice, it’s will still be unsafe anyway), or > 2. prioritize the ability to maximize multicore performance, but allow interpreter state anomalies when things are not used correctly. It’s the programmer’s responsibility to do threading correctly. This is a non starter, it’s just buggy. It is true that multi-threaded programming is harder than single-threaded programming. The PEP does include some safety guarantees and locks, e.g. to containers. Using multi-threading is not mandatory, and if a programmer does not want to take on the responsibility and does not want to bother with thread safety, they can just continue writing single-threaded code and have more safety (although even with a single thread and no concurrency at all, you can mess up in other areas as well if you are not careful about what your code does and how it behaves in various scenarios.) > [@miraculixx](#): > > Last but not least I think Python should avoid any other opportunity for being labeled backward incompatible. If you look at the lists of things removed in recent Python versions in What’s New documents (e.g. [3.11](https://docs.python.org/3.12/whatsnew/3.11.html#removed)) and at porting instructions in the same documents, you might notice Python does not guarantee that 100% of code that worked under Python 3.n will work under Python 3.(n+1) without changes. So yes, you can easily label 3.11 as backwards-incompatible with 3.10. > [@guido](#): > > (Moderator can you do something to slow down this thread?) (Please don’t silence the discussion, that won’t do Python any good.) ---
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [July 12, 2023, 7:40pm UTC](https://discuss.python.org/t/a-fast-free-threading-python/27903/147 "2023-07-12T19:40:06Z")
Closed on July 12, 2023, 7:40pm UTC ---
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [July 12, 2023, 7:47pm UTC](https://discuss.python.org/t/a-fast-free-threading-python/27903/148 "2023-07-12T19:47:06Z")
Closing for essentially the same reasons as [PEP 703: Making the Global Interpreter Lock Optional (3.12 updates) - #155 by davidism](https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-3-12-updates/26503/155). This discussion has begun to go in circles, with new people showing up who are repeating questions and topics that have already been well covered previously. The developers working on the GIL removal and other faster Python initiatives are all aware of the issues surrounding it, and are taking them into account. Work is being done, and changes are not being made lightly or without consideration. At this point, discussion about this topic should focus on specific technical points, not high level guesses about how things might work. There is a reference implementation, and years of discussion, to refer to. I’m sure the developers would appreciate more people trying these things out and contributing reports or patches to fix real issues, so please focus further efforts there. [Previous page](https://discuss.python.org/t/a-fast-free-threading-python/27903.md?page=7)