Re: [pypy-dev] Re: [Numpy-discussion] Better compatibility of the Python scientific/data stack with fast Python interpreters
On Wed, Apr 30, 2025 at 3:30 PM Michał Górny <mgorny@gentoo.org> wrote:
Hello,
I'd like to just add a few data points from my Gentoo experience. ... I'm sorry but I don't understand what you're referring to. Sure, PyPy is not moving fast, but it definitely isn't dead. Sure, it sucks that we're still stuck in Python 3.11 era, but that doesn't make PyPy EOL.
-- Best regards, Michał Górny
It does not appear there will be a PyPy 3.12. When NumPy drops support for Python3.11 (Jan 2026), future versions based on the CPython C-API will defacto no longer be relevant for PyPy3.11. However, if HPy succeeds, there is a chance that a NumPy "universal" HPy wheel will still work on PyPy 3.11, as the API will be abstracted away from a direct connection with the CPython C-API. This is one of the attractions of HPy, that puts it in a different category than Cython or nanobind: universal HPy binaries can run on any python interpreter or version that supports the abstracted API.
With the current level of active contributions to PyPy, I am not convinced we can help making HPy a reality, even though it is a very well thought out solution to once and for all detaching third party libraries from a tight integration with the CPython C-API. I agree HPy would be advantageous to both the CPython core team and package maintainers. The yearly churn of packages needing to update for new CPython C-API would be localized in the HPy layer for the new CPython (similar to Cython, nanobind, and PyO3), and the CPython maintainers would be free to change more aspects of the CPython internals that unintentionally impact the external C-API (which differentiates HPy from Cython, nanobind, and PyO3). But not all good ideas get to win out and become the popular, goto solution. PyPy itself is an example that, unfortunately. Matti
Thanks Matti for this interesting and sad piece of news.
I also reply on numpy-discussion@python.org since your message was not post on this list and take the opportunity to signal another important post about his subject on discuss.python.org by Stepan Sindelar:
https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c-...
IMHO, anyone interested in the long term future of Python should be aware of these issues.
Pierre
----- Mail original -----
De: "matti picus via hpy-dev" <hpy-dev@python.org> À: "PyPy Developer Mailing List" <pypy-dev@python.org>, "Ralf Gommers" <rgommers@quansight.com>, "hpy-dev" <hpy-dev@python.org> Envoyé: Vendredi 2 Mai 2025 10:05:51 Objet: [hpy-dev] Re: [pypy-dev] Re: [Numpy-discussion] Better compatibility of the Python scientific/data stack with fast Python interpreters
On Wed, Apr 30, 2025 at 3:30 PM Michał Górny <mgorny@gentoo.org> wrote:
Hello,
I'd like to just add a few data points from my Gentoo experience. ... I'm sorry but I don't understand what you're referring to. Sure, PyPy is not moving fast, but it definitely isn't dead. Sure, it sucks that we're still stuck in Python 3.11 era, but that doesn't make PyPy EOL.
-- Best regards, Michał Górny
It does not appear there will be a PyPy 3.12. When NumPy drops support for Python3.11 (Jan 2026), future versions based on the CPython C-API will defacto no longer be relevant for PyPy3.11. However, if HPy succeeds, there is a chance that a NumPy "universal" HPy wheel will still work on PyPy 3.11, as the API will be abstracted away from a direct connection with the CPython C-API. This is one of the attractions of HPy, that puts it in a different category than Cython or nanobind: universal HPy binaries can run on any python interpreter or version that supports the abstracted API.
With the current level of active contributions to PyPy, I am not convinced we can help making HPy a reality, even though it is a very well thought out solution to once and for all detaching third party libraries from a tight integration with the CPython C-API. I agree HPy would be advantageous to both the CPython core team and package maintainers. The yearly churn of packages needing to update for new CPython C-API would be localized in the HPy layer for the new CPython (similar to Cython, nanobind, and PyO3), and the CPython maintainers would be free to change more aspects of the CPython internals that unintentionally impact the external C-API (which differentiates HPy from Cython, nanobind, and PyO3). But not all good ideas get to win out and become the popular, goto solution. PyPy itself is an example that, unfortunately. Matti
hpy-dev mailing list -- hpy-dev@python.org To unsubscribe send an email to hpy-dev-leave@python.org https://mail.python.org/mailman3/lists/hpy-dev.python.org/ Member address: pierre.augier@univ-grenoble-alpes.fr
participants (2)
-
matti picus -
PIERRE AUGIER