Mailman 3 - NumPy-Discussion

Translations project - Crowdin migration
by Melissa Mendonça May 12, 2025

May 12, 2025

Hi all, We recently moved the numpy.org translations project on crowdin to the Scientific Python crowdin instance, so it benefits from the automations and workflows we have recently developed there for multiple others projects such as SciPy, pandas, xarray, zarr and networkx. To prevent folks from translating on the wrong crowdin project, I would like to do 2 things: 1. Send a message to all translators on our old crowdin project, with the following text: ``` Hello, We would like to inform you that the translations for the NumPy.org website have been migrated to a new crowdin instance. To continue helping with translations for NumPy.org, please read the documentation for the Scientific Python translation projects at https://scientific-python-translations.github.io/translate Thanks! ``` 2. Close/delete/archive that old crowdin project so folks don't reach it by accident. I'd love to get some feedback from other maintainers on this. I have also added this comment to the meta-issue about translations: https://github.com/numpy/numpy.org/issues/55#issuecomment-2873315677 If there are no concerns, I propose sending the message in the next 48h and closing the old project in the next week or so. Thanks, - Melissa

1 0

next NumPy triage meeting - Wednesday, January 22nd, 2025 at 6 pm UTC
by Inessa Pawson May 11, 2025

May 11, 2025

The next NumPy triage meeting will be held this Wednesday, January 22nd at 18:00 UTC. As always, this is a meeting where we synchronously triage prioritized PRs and issues. Everyone is welcome to attend and contribute to a conversation. Join us via Zoom: https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVX… Please notify us of issues or PRs that you’d like to have reviewed by adding a GitHub link to them in the meeting agenda: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 7

Dropping PyPy in NumPy 2.3
by Charles R Harris May 8, 2025

May 8, 2025

Hi All, Just thought I would raise the topic of PyPy status in NumPy 2.3. PyPy for Python 3.11 currently has a bug which has hung around for a while, and it is also likely that there will be no PyPy for Python 3.12. It looks like PyPy is reaching end of life, and this seems a good time to decide if we should continue releasing wheels for it. Thoughts? Chuck

2 1

Better compatibility of the Python scientific/data stack with fast Python interpreters
by PIERRE AUGIER May 7, 2025

May 7, 2025

Dear Numpy community members and Numpy developers, This email is to get the points of view of the Numpy community members and developers about a subject that I find very important. I'm going to introduce it just in few lines so I write few statements without backing them with proper arguments and without giving links and word definitions. I assume that most people registered to the numpy-discussion list are at least familiar to the subject. I think getting proper compatibility of the Python scientific/data stack with fast Python interpreters is very important for the long-term future of Python for science and data. Nowadays, fast Python implementations like PyPy and GraalPy are - complicated to use (need local builds of wheels) - slow as soon as the code involves Python extensions (because extensions work through an emulation layer, like cpyext in PyPy) Therefore, these fast Python implementations are not as popular as they should be. However, they are really great tools which should be used in particular for scientific/data applications. Unfortunately, if we just follow the pace of the CPython C API evolution, we will basically never have an ecosystem natively compatible with fast Python implementations. The more I think and learn about this subject, the more I think that Numpy has to stop using directly the CPython C API and to be ported to HPy (though there are other alternatives - in particular Nanobind and Cython - that could be discussed). Numpy 1 has been ported to HPy but unfortunately, there have been deep changes with Numpy 2 (and Meson) so it seems that one should restart the porting. Moreover, unfortunately, HPy does not currently receive as much care as it should. It seems to me that the project of fixing the roots of the Python ecosystem has to be relaunched. I think that the dynamics has to come from the Python scientific/data community and in particular Numpy. It is unfortunately outside of the C API working group's scope (see https://discuss.python.org/t/c-api-working-group-and-plan-to-get-a-python-c…). It seems to me that it is necessary (and possible) to get some founding for such an impactful project so that we can get people working on it. I'd like to write a long and serious text on this subject, and I first try to get the points of view of the different people and projects involved. I guess I should write explicit questions: - What do you think about the project of fixing the Python scientific/data stack so that it becomes natively compatible (hence fast and convenient, with easy installations) with alternative and fast Python interpreters? - Do you have points of view on how this should be done, technically (HPy?, something else?) and on other aspects (community, NEP?, founding, ...). - Anything else interesting on this subject? Best regards, Pierre -- Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels BP53, 38041 Grenoble Cedex, France tel:+33.4.56.52.86.16

3 7

Announce: passagemath-modules 10.5.30
by Matthias Köppe May 5, 2025

May 5, 2025

passagemath-modules (https://pypi.org/project/passagemath-modules/) is one of the pip-installable components of the modularized SageMath library, developed by the passagemath project. It supports CPython 3.9-3.13 on Linux and macOS and provides binary wheels for these platforms on PyPI. passagemath-modules provides vectors, matrices, tensors, vector spaces, affine spaces, modules and algebras, additive groups, quadratic forms, homology, coding theory, matroids. When using double-precision floating-point numbers as the base ring, passagemath-modules uses NumPy (and SciPy) as the computational backend.

1 0

Re: [hpy-dev] Re: [pypy-dev] Re: Better compatibility of the Python scientific/data stack with fast Python interpreters
by PIERRE AUGIER May 5, 2025

May 5, 2025

Thanks Matti for this interesting and sad piece of news. I also reply on numpy-discussion(a)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(a)python.org> > À: "PyPy Developer Mailing List" <pypy-dev(a)python.org>, "Ralf Gommers" <rgommers(a)quansight.com>, "hpy-dev" > <hpy-dev(a)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(a)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(a)python.org > To unsubscribe send an email to hpy-dev-leave(a)python.org > https://mail.python.org/mailman3/lists/hpy-dev.python.org/ > Member address: pierre.augier(a)univ-grenoble-alpes.fr

1 0

next Documentation team meeting
by Mukulika Pahari May 5, 2025

May 5, 2025

Hi all, Our next Documentation Team meeting will happen on *Monday, July 15* at *7PM UTC*. All are welcome - you don't need to already be a contributor to join. If you have questions or are curious about what we're doing, we'll be happy to meet you! If you wish to join on Zoom, use this (updated) link: https://numfocus-org.zoom.us/j/85016474448?pwd=TWEvaWJ1SklyVEpwNXUrcHV1YmFJQ... Here's the permanent hackmd document with the meeting notes (still being updated): https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg Hope to see you around! Best wishes, Mukulika

2 18

next NumPy community meeting - Wednesday, April 9th, 2025 at 5 pm UTC - now meeting ONE HOUR EARLIER
by Inessa Pawson May 3, 2025

May 3, 2025

The next NumPy community meeting will be held this Wednesday, April 9th at 17:00 (5 pm) UTC. Please note the TIME CHANGE! Join us via Zoom: https://numfocus-org.zoom.us/j/83278611437?pwd=ekhoLzlHRjdWc0NOY2FQM0NPemdk… Everyone is welcome and encouraged to attend. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both For the notes from the previous meetings, visit: https://github.com/numpy/archive/tree/main/community_meetings -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 2

Add Sampling with Dynamic weights with replacement to np.random.choice
by Shourya Jain May 2, 2025

May 2, 2025

Feature request : Add replacement based sampling method with weight decay for choosing samples from a list/array I would like to add it with an algorithm as follows : for _ in range(target_size): idx = np.random.choice(a, 1, p=p) # Get a sample samples.append(a[idx]) # Append sample to samples list p[idx] *= decay_factor # Update probabilities p /= np.sum(p) # Normalize probabilities This provides a more representative sample than normal sampling with replacement as elements that have not been sampled get higher probability of being sampled later. I would like to add it to the np.random.choice itself, by adding a parameter decay_factor that defaults to 1

2 1

next NumPy Optimization Team meeting - Monday, January 20th, 2025 at 5 pm UTC
by Inessa Pawson May 2, 2025

May 2, 2025

Hi, all! The next NumPy Optimization Team meeting will be held on Monday, January 20th at 17:00 UTC. Join us via Zoom: https://numfocus-org.zoom.us/j/81261288210?pwd=iwV99tGSjR61RTGEERKM4QKxe46g… Everyone is welcome and encouraged to attend. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/dVdSlQ0TThWkOk0OkmGsmw?both For the notes from the previous meetings, visit: https://github.com/numpy/archive/tree/main/optim_team_meetings -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 5