Nathan Goldbaum

I'm able to build the Python bindings using 3.14.0t if I update the build dependencies: ```diff diff --git a/api/python/build-requirements.txt b/api/python/build-requirements.txt index 729d9c97..c9f98fb6 100644 --- a/api/python/build-requirements.txt +++ b/api/python/build-requirements.txt @@ -1,10 +1,10...

> but LIEF main API is not thread safe which means (if I'm not wrong) that the bindings should manage all the mutex and the threading sync That's true, but...

> So view in some sense should be considered unsafe because it can be used to violate this assumption. IMO rust-numpy should add checks like what OP proposes to the...

Ah, fair enough. Seems like another issue similar to what Alex Gaynor describes regarding the buffer protocol: https://alexgaynor.net/2022/oct/23/buffers-on-the-edge/ Numpy could opt to add more checks to support Rust's safety needs,...

I agree. Not only is it duplicative but also the `fix` implementation is inefficient: ``` In [4]: arr = np.random.random(1_000_000)*1000 In [5]: %timeit np.trunc(arr) 426 μs ± 15.1 μs per...

ping @athurdekoos as well

We've had a couple other recent bug reports that this error message is showing up in cases where it doesn't make sense. Basically, this error happens when something is deeply...

I looked more at free-threaded support today. I looked a little at making the pyclasses in the python bindings `frozen` to opt out of runtime borrow-checking, but that is currently...

> I'm planning to open a PR shortly see #1809

I tried testing on 3.14.0t RC1 but it looks like that's blocked on `hf-xet` updating to a newer PyO3: ``` --- stderr error: The configured Python interpreter version (3.14) is...