Mailman 3 April 2025 - NumPy-Discussion

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

June 5, 2026

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 23

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

May 16, 2026

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 29

Fixing definition of reduceat for Numpy 2.0?
by Martin Ling Feb. 27, 2026

Feb. 27, 2026

Hi folks, I don't follow numpy development in much detail these days but I see that there is a 2.0 release planned soon. Would this be an opportunity to change the behaviour of 'reduceat'? This issue has been open in some form since 2006! https://github.com/numpy/numpy/issues/834 The current behaviour was originally inherited from Numeric, and makes reduceat often unusable in practice, even where it should be the perfect, concise, efficient solution. But it has been impossible to change it without breaking compatibіlity with existing code. As a result, horrible hacks are needed instead, e.g. my answer here: https://stackoverflow.com/questions/57694003 Is this something that could finally be fixed in 2.0? Martin

6 12

next NumPy Newcomers' Hour - June 27th, 2024 at 10 pm UTC
by Inessa Pawson Sept. 13, 2025

Sept. 13, 2025

Our next Newcomers' Hour will be held TOMORROW, June 27th at 10 pm UTC. Stop by to ask questions, share your progress, celebrate success, or just to say hi. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/3f3otyyuTte3FU9y3QzsLg?both. Join the meeting via Zoom: https://us06web.zoom.us/j/82563808729?pwd=ZFU3Z2dMcXBGb05YemRsaGE1OW5nQT09. -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 11

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

May 18, 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 9

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

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

Fwd: Research Opportunity: Can we monitor your projects?
by Charles R Harris April 30, 2025

April 30, 2025

Just thought I'd pass this along for discussion. Chuck ---------- Forwarded message --------- From: <webmaster(a)cse.unl.edu> Date: Tue, Apr 29, 2025 at 4:09 PM Subject: Research Opportunity: Can we monitor your projects? To: Charles Harris <charlesr.harris(a)gmail.com> Hello Charles Harris, I'm Samuel Flint, and I'm working with Dr. Robert Dyer from the University of Nebraska-Lincoln on a study about type annotations in dynamic languages. We would like your permission to monitor the following project(s), which are highly relevant to our research, and for which you are maintainer: - numpy/numpy (https://github.com/numpy/numpy) If you agree, we will provide a bot that tracks changes related to type annotations. The bot will notify committers after relevant changes, asking them to participate in the study (no more than once every 24 hours, and they can opt-out or request data removal at any time). Would you be willing to have us monitor your project(s)? If so, please install the bot using the instructions here: https://github.com/apps/typechangebot Additional help is available from GitHub ( https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-f… ). Thanks for considering! Samuel W. Flint and Robert Dyer This study as been approved by the University of Nebraska-Lincoln Institutional Review Board ( https://research.unl.edu/researchcompliance/human-subjects-research/) with the title "Understanding Developers' Addition and Removal of Type Annotations", IRB# 23988.

5 5

ENH: Add saturating arithmetic functions
by Carlos Martin April 28, 2025

April 28, 2025

Saturating arithmetic (https://en.wikipedia.org/wiki/Saturation_arithmetic) is important in digital signal processing and other areas. Feature request: Add saturating arithmetic functions for the following basic operations: - addition (C++ counterpart: https://en.cppreference.com/w/cpp/numeric/add_sat) - subtraction (C++ counterpart: https://en.cppreference.com/w/cpp/numeric/sub_sat) - multiplication (C++ counterpart: https://en.cppreference.com/w/cpp/numeric/mul_sat) - division (C++ counterpart: https://en.cppreference.com/w/cpp/numeric/div_sat) - casting (C++ counterpart: https://en.cppreference.com/w/cpp/numeric/saturate_cast) - negation I've implemented these for JAX at https://gist.github.com/carlosgmartin/b32fa6fed3aa82f83dfbaac4b6345672. Corresponding issue: https://github.com/jax-ml/jax/issues/26566.

3 2

StringDType scalar type
by Mateusz Sokol April 28, 2025

April 28, 2025

Hi all! There's an ongoing discussion about introducing a dedicated scalar type for `StringDType`. One of the remarks was that the scope of the change is large enough so it deserves a separate paragraph in the NEP 55. It's also vital to collect more opinions from the community before the actual work, therefore here's a list of active discussion threads: - An official issue for StringDType scalar: https://github.com/numpy/numpy/issues/28165 - PR which updates NEP 55 to describe StringDType scalar: https://github.com/numpy/numpy/pull/28842 - Draft PR meant to ship the feature (goes after NEP 55 update): https://github.com/numpy/numpy/pull/28196 Please share your thoughts! Best regards, Mateusz

1 0