# Pre-PEP: Safe Parallel Python

**URL:** <https://discuss.python.org/t/pre-pep-safe-parallel-python/103636>\
**Category:** Ideas\
**Created:** [September 8, 2025, 9:25pm UTC](https://discuss.python.org/t/pre-pep-safe-parallel-python/103636 "2025-09-08T21:25:20Z")\
**Posts on this page:** 1\
**Showing post:** 31

<div class="post-metadata">

**Author:** ![matthewyu0311](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/matthewyu0311/32/20118_2.png) [@matthewyu0311](https://discuss.python.org/u/matthewyu0311)\
**Post date:** [October 6, 2025, 1:37pm UTC](https://discuss.python.org/t/pre-pep-safe-parallel-python/103636/31 "2025-10-06T13:37:45Z")

</div>

> [@jbosboom](#):
>
> Unfortunately PEP 703 makes handwavy statements like “per-object locking aims for similar protections as the GIL” instead of listing, even incompletely, the protections it aims to provide, though the thorough implementation details do implicitly list some of them

Great research on Python literature. The implicit memory model is really “whatever CPython happened to have implemented at the time PEP 703 was written”. By promising “per-object locking aims for similar protections as the GIL” it implies a sequential memory model with atomic behavior for builtin objects. Only when free-threading gains widespread use can we see how well the promise really holds up.

> [@jbosboom](#):
>
> and I expect PEP 703 to fail in practice because it does not attempt to define one

I don’t think this would necessarily be the case, but it does seem that the various projects to enhance Python (free-threading, JIT, etc.) are sometimes not really tuned to the same wavelength. And here goes the classic open-source project management problem: “Organization A has successfully forked a software to implement feature A for their own use cases” and “Organization B has successfully forked a software to implement feature B for their own use cases” does not mean that we can make the mainline implement features A and B simultaneously without hassle. This is _especially_ the case in Python as enhancements are often driven by enterprise- and domain-particular needs. The current proposal focuses on enabling JIT specialization (for which ` __shared__ ` state is useful) but doesn’t go as far as writing machine-specific assembly on-the-fly — in any case we still need to state _what actually limits the future potential JIT from going so low-level_. (In other words, write down why low-level JIT is a bad idea in Python.)

---

_[View the full topic](https://discuss.python.org/t/pre-pep-safe-parallel-python/103636)._