-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Numpy 2.0 #660
Comments
It would be nice. My understanding is that it requires Cython support first.
|
I took a look at the builds error, and seems it is a Cython problem as reported in cython/cython#6249
So, totally agree with you @mrjbq7 , we should wait for a Cython stable support. |
Just pointing out that building from the latest trunk I get a successful build that works with numpy 2. I don't know how you plan to support numpy 2 vs 1 moving forward, I don't think it's possible to support both, you might want to do a somewhat larger version bump to indicate numpy 2 only versions moving forward. But I believe there's not really a blocker to releasing a numpy 2 version of TA-Lib at this point. |
I would imagine supporting numpy1 is something people might want for some time, what are other projects doing? Building with the compat layer?
|
I'm not aware of any compatibility layer for Numpy C API For example https://github.com/explosion/spaCy released v3.8.0 with numpy 2 support, while v3.7.x has numpy 1 support, so bumping the version in a way that would allow easily pinning (e.g. <0.5 vs >=0.5) would probably be helpful |
The Numpy 2.0 Migration Guide mentions the idea of including Anyway, given how slowly some places update libraries, it makes me wonder if having a hard version split against numpy 2 is a good idea or not... |
Ah I see on PyPI you're releasing only a tarball and not a wheel, so technically since you're distributing sources you might get compatibility with both numpy 1 and numpy 2 There's still a problem that whatever you specify on your dependencies goes, so once you have numpy 2 allowed there (by dropping the numpy<2 part) it will pick numpy 2 by default But there's ways for those who want to enforce numpy 1 to keep that, e.g. by using |
HI,
As reported in conda-forge/ta-lib-feedstock#45 ta-lib builds are failing against future Numpy 2.0. Any plans to support this? If so we can use this issue to track the implementation.
The text was updated successfully, but these errors were encountered: