# 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:** 26

<div class="post-metadata">

**Author:** ![dpdani](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dpdani/32/14107_2.png) [@dpdani](https://discuss.python.org/u/dpdani)\
**Post date:** [September 26, 2025, 5:38pm UTC](https://discuss.python.org/t/pre-pep-safe-parallel-python/103636/26 "2025-09-26T17:38:27Z")

</div>

Now, I had a few points I wanted to make after reading the PEP a few times.

### Optimistic lock avoidance for lists and dicts

Under this proposal, lists and dicts can be immutable (freezed), local, stop-the-world mutable, and protected, but not synchronized, right? If that is so, does it mean that the optimistic reads detailed in [PEP 703](https://peps.python.org/pep-0703/#optimistically-avoiding-locking) would no longer be necessary? I reckon that would simplify a lot of code inside CPython.

### SuperThreads

The name `SuperThread` doesn’t make me think about GIL-like serialization of threads. Maybe we can bikeshed on a better name? I found `SerializedThreadGroup` in [§With the GIL enabled](https://pep-previews--4579.org.readthedocs.build/pep-0805/#with-the-gil-enabled), that sounds like a better name to me.

### 

### About ` __protect__ ()`

I tried coming up with a simple pure-Python mutex implementation based on this PEP, that would also resemble a Rust mutex. (Granted, it’s very easy to implement a mutex when you already have `*. __mutex__ `.)  
I stumbled on this problem: is a previously-protected object allowed to no longer be protected? I think the code below illustrates why it might be useful.

```python
class Mutex:
    def __init__ (self, obj):
        self.protected = self. __protect__ (obj)

    class UnlockedMutex:
        def __init__ (self, mx: Mutex):
            self.mx = mx
            self. __freeze__ ()

        def get(self):
            return self.mx.protected

        def set(self, obj):
            # previous = self.mx.protected
            self.mx.protected = self.mx. __protect__ (obj)
            # self. __unprotect__ (previous) <---- is this needed? is it implicit?

    @contextlib.contextmanager
    def lock(self):
        with self. __mutex__ :
            yield self.UnlockedMutex(self)

```

Given the above, what would be the result of this code?

```python
my_mutex = Mutex({})

with my_mutex.lock() as unlocked_mx:
    current = unlocked_mx.get()
    updated = current | {"spam": True}
    unlocked_mx.set(updated)
    # current is now the sole reference to the empty dict used above

print(current) # is this ok? was it implicitly un-protected? or does it raise?

```

Another question. [This table](https://pep-previews--4579.org.readthedocs.build/pep-0805/#semantics) says “no” under immutable x ` __protect__ ()`.  
Does that mean the following code would raise an exception?

```python
my_mutex = Mutex(0)

```

Yet another question. What does this do?

```python
self. __protect__ (self)

```

Do I take it correctly that it means _in order to change the attributes of `self`, from now on you’ll need to hold `self. __mutex__ `_? If so, I guess the `Mutex. __init__ ()` above needs it, right?

### On the benefits of this proposal

I would like to point out a few characteristics that make this simple Mutex worthwhile, because I think they really are benefits of this PEP.

```python
my_list = []
my_mutex = Mutex(my_list) # raises
# as desired: prevents the reference from escaping the mutex's scope.
# => can't mutate the list without calling my_mutex.lock()

```

```python
my_mutex = Mutex([])

with my_mutex.lock() as unlocked_mx:
    lst = unlocked_mx.get()
    lst.append("spam")

lst.append("nope!") # raises: this thread does not hold my_mutex. __mutex__
# again, prevents the reference from escaping the mutex.

```

I think it would be tremendously useful to have the guarantee of holding the sole reference to an object, especially in a multithreading context.

Furthermore, incrementally opting out of the GIL with “SuperThreads” sounds definitely less scary than switching from all-GIL to no-GIL. For anybody, beginners and experts alike. It would probably help the adoption of free-threading in the long run.

---

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