David Hewitt

One question I have is about FFI smart pointers, which were one of the key use cases for arbitrary self types. If I understand correctly, these smart pointers cannot easily...

I see, I think you might also be able to do something like `trait MyTraitRefCounted: MyTrait + AlwaysRefCounted` when it's not possible to modify `MyTrait` directly. For `Py` in PyO3...

> > (If it is not ok to move it when unlocked, we will need to do more complicated APIs which make use of pinning, I fear...) > > This...

We could probably write a test that it deadlocks by spawning a thread and allowing that thread to deadlock, and can assert that thread doesn't run to completion after e.g....

Probably missing `unsafe impl Sync for PyMutex {}` ?

That handling of poisoning seems totally fine to me. With regard to panics across call stacks, if we `PyErr::fetch` an exception which looks like it was a panic previously converted...

I sent an email; will wait a bit for a response before considering further options.

I think this evening I will set up a fork in the PyO3 organization which users can at least benefit from as a git dependency to fix the immediate problem....

As per https://github.com/awestlake87/pyo3-asyncio/issues/119#issuecomment-2166720029 While waiting for a permanent decision on what to do, I've published https://crates.io/crates/pyo3-asyncio-0-21 from a fork at https://github.com/davidhewitt/pyo3-asyncio @awestlake87 has put a lot of effort into this...

Probably, yes. I have some family duties to take care of first and will probably help complete PyO3 0.22.1 patch release too before I get to this.