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-api-compatible-with-alternative-python-implementations/89477/19 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-...@python.org> > À: "PyPy Developer Mailing List" <pypy-...@python.org>, "Ralf Gommers" > <rgomm...@quansight.com>, "hpy-dev" > <hpy-...@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 <mgo...@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-...@python.org > To unsubscribe send an email to hpy-dev-le...@python.org > https://mail.python.org/mailman3/lists/hpy-dev.python.org/ > Member address: pierre.aug...@univ-grenoble-alpes.fr _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
