Update pyo3 and numpy crate versions to support python 3.13

[ncoish]

Support for python 3.13 was added to PyO3 in version 0.22. The main purpose of this PR is to add this support to fastpdb.

Additionally I bumped the version of the numpy crate to pick up the latest changes. This is optional though, and if you think there are any problems with this I can remove the update.

[codspeed-hq]

CodSpeed Performance Report

Merging #21 will improve performances by 26.1%

_{Comparing ncoish:support-py3.13 (888e09f) with main (6db4fcf)}

🎉 Hooray! pytest-codspeed just leveled up to 3.2.0!

A heads-up, this is a breaking change and it might affect your current performance baseline a bit. But here's the exciting part - it's packed with new, cool features and promises improved result stability 🥳!
Curious about what's new? Visit our releases page to delve into all the awesome details about this new version.

Summary

⚡ 1 improvements
✅ 6 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	test_read	2.1 ms	1.6 ms	+26.1%

[ncoish]

I'm not sure if the test failures are due to something that I changed. It looks like there might be a missing github action?

[ncoish]

I'm not sure if the test failures are due to something that I changed. It looks like there might be a missing github action?

Okay, all fixed up! I'm not sure if the modifications to the upload step I made are correct though, @padix-key would you mind checking to make sure I didn't make any mistakes?

[ncoish]

The benchmarks might also be misleading, since I swapped the CI to start using python 3.13 instead of 3.12. I'm not entirely familiar with github's CI though, so maybe the benchmarks are being run with 3.13 in both the "before" and "after" state, in which case it's a fair comparison.

[padix-key]

Thanks for updating the build pipeline, the changes look correct to me! Below I only propose another small change
Sorry for the late response, the PR slipped through my attention.

so maybe the benchmarks are being run with 3.13 in both the "before" and "after" state

No, the benchmarks compare this CI run (with Python 3.13) with the latest CI run on main (with Python 3.12). So the results of the benchmarks shows that Python 3.13 is significantly faster in some tasks

[ncoish]

I've made the recommended suggested change, but modified it to look for any numpy version 1.26.x, because for some reason pip is failing to find 1.26 specifically.

[padix-key]

There is currently a segmentation fault in the CI when executing pytest. However as the changes in this PR do change source code, I suppose this is some temporary error. If not, we can try reverting the latest commit in this PR.

[ncoish]

There is currently a segmentation fault in the CI when executing pytest. However as the changes in this PR do change source code, I suppose this is some temporary error. If not, we can try reverting the latest commit in this PR.

Should we try just re-triggering the pipeline? I'm not sure what the best way is to gain confidence that this is purely spurious and not a real issue with the code. That being said, you're right: It does seem to specifically be pytest that's segfaulting.

[ncoish]

There is currently a segmentation fault in the CI when executing pytest. However as the changes in this PR do change source code, I suppose this is some temporary error. If not, we can try reverting the latest commit in this PR.

Looks like reverting the latest commit fixes things. I'll remove the extra commits and force-push back to where it was succeeding.

[ncoish]

I think the assets failed to upload in the release after this PR was merged.

[padix-key]

This oversight is caused by a previous PR. #22 will fix it