Nathan Goldbaum

For torch, there are free-threaded PyTorch 2.6 wheels for Linux, so at least on Linux that’s unblocked. https://github.com/pytorch/pytorch/issues/130249 Not sure about other dependencies, I haven’t started looking closely at this...

> Well that's not really enough to claim support overall in release binaries is it ? No definitely not, I’m more talking about experimenting with the free-threaded build being unblocked....

I think the issue you’re describing is more or less what Alex Gaynor is talking about here? https://alexgaynor.net/2022/oct/23/buffers-on-the-edge/ I’m not sure there is a safe way to expose objects implementing...

As of July 2025 there are now torch nightlies available on all platforms. Right now support for 3.13t is experimental, https://github.com/pytorch/pytorch/issues/156854 tracks stable support for 3.13t. Another wrinkle is that...

I managed to trigger internal asserts or segfaults in PyTorch by mutating a tensor while safetensors is serializing it: https://github.com/pytorch/pytorch/issues/158071

Here's a patch on top of current `main` to get things to build: https://gist.github.com/ngoldbaum/ea251bb5abb10c1b46fc6bceca8ac606

> I don't support using one Packer from multiple threads, regardless free threding or with GIL. Fair enough. I don't see that documented anywhere - maybe it should be? If...

msgpack 1.1.2 has free-threaded wheels: https://pypi.org/project/msgpack/#files I think this can be closed now.

I'm able to reproduce random failures and seg faults on this test using the wheel. I think rebuilding it will make this test more stable. That said, I do see...

I had a chat with @ambv over discord and he managed to find the upstream problem: https://github.com/python/cpython/issues/121368. Closing in favor of that since this is unrelated to pywavelets.