Frank Steffahn

And now, here’s another argument why `allow_threads` should better require `Send`, even if `pyclass` enforced `Sync`: The `GILProtected` wrapper! ```rs use std::cell::Cell; use std::thread; use pyo3::prelude::*; use pyo3::sync::GILProtected; fn main()...

On naming, I don’t like the `unsafe` or `safe` in the name. All safe API is safe, no need to spell it out, and unsafe API doesn’t need to put...

It’s not really a “check” we’re skipping but a trait bound / constraint. Maybe `unconstrained`? (Or `no_send`, or `no_send_bound`.) It’s *also* still local, and longer names for more unsafe API...

> But this is not true, right? Because I could also use `scoped-tls` to smuggle the GIL token itself even if it has a generative lifetime attached? Yes. At least...

```rs use pyo3::prelude::*; use scoped_tls_hkt::scoped_thread_local; fn main() { Python::with_gil(|py| { scoped_thread_local!(static GIL: for); GIL.set(py, || { py.allow_threads(|| { GIL.with(|smuggled_py: Python

FYI, I came across this issue from [a context of discussing the role of `Send`/`Sync` on IRLO](https://internals.rust-lang.org/t/non-send-futures/20016). Asynchronous tasks have a similar problem as `Ungil`, as they would love to...

> EDIT: Maybe we would need a completely need thread for soundness? Or we would need to track whether the GIL was ever acquired on these runtime threads? Probably enought...

> * When you temporarily release the GIL you have to return that mutable reference for the time it is released via reborrowing. That sounds, I think, like it would...

> Comparing this to what I see PyO3 currently implements, it looks like the main difference is that the lifetime on `Python` token. After all, `&'a mut T` is *covariant*...

> > polonius-the-crap > > :sob: OMG, sorry, what a typo 🤣