I think assuming refcnt == 1 means that it's safe to mutate it is not safe. It's not safe in both the free-threaded and the regular build. I don't know how much performance would be lost by disabling this. You might check that Python version is < 3.13 since the upcoming release will have more ways to break this assumption (was already broken in <= 3.12, I think).

There is a new API being proposed for CPython:
python/cpython#133170

The Py_REFCNT(obj) == 1 check is fine here. There obj comes from a PyBytes_FromStringAndSize() call. There are only two cases:

• PyBytes_FromStringAndSize() returns a new bytes object with refcount of 1. Nobody else has access to it, so it's safe to resize in-place.
• PyBytes_FromStringAndSize() returns an interned, immortal bytes object. The refcount is not one (it's some large value) and we don't resize it.

There's no concern about racing accesses to the refcount here in the free threading build. It's a lot more straightforward than the NumPy because the PyBytesObject is coming from python-zstandard code, not from some Python call.

I've cherry picked this and will push it directly. PR will be marked as closed but it is in fact merged.

Thanks @indygreg! Appreciate your great work on this.

I thought I saw this commit pass CI. But it definitely resulted in crashes after the merge to main. So I'm reverting it. https://github.com/indygreg/python-zstandard/actions/runs/17011229024

Some of the wheel build logs show a compiler error likely pointing at the source of the bug. https://github.com/indygreg/python-zstandard/actions/runs/17011229015/job/48227527781