Mailman 3 November 2025 - NumPy-Discussion

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

July 17, 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 25

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

July 11, 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 32

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 triage meeting - Wednesday, May 28th, 2025 at 5 pm UTC
by Inessa Pawson Jan. 4, 2026

Jan. 4, 2026

The next NumPy triage meeting will be held this Wednesday, May 28th at 17:00 (5 pm) UTC. 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 14

ENH: Add float16, npy_half, specific routines to the NumPy C-API as NpyHalf*
by Amelia Thurdekoos Dec. 11, 2025

Dec. 11, 2025

Current situation float16, npy_half, is currently handled through a set of helper functions located in numpy/halffloat.h and implemented in npymath. This requires linking against the libnpymath.a, a static library. Linking against a static library is problematic as a static library built with one compiler often cannot be linked with an application built with a different compiler. See #20880 <https://github.com/numpy/numpy/issues/20880>. Goal Expose halffloat.h functionality through the regular NumPy C-API as NpyHalf*, without requiring the linking of npymath explicitly as a step toward removing the npymath static library altogether. Proposed ImplementationSummary - I propose to add a new NumPy C-API file in the multiarray C extension directory as NpyHalf*, with the primary design objective to eliminate the need for an explicit link to libnpymath.a. Implementation Specifics - All functionality currently available in include/halffloat.h will be duplicated into multiarray/*.h, which will be the primary entrance point of the API. Whether the include/halffloat.h functionality will be duplicated in its own file, or incorporated into an existing header, is still an open question. - The naming convention will be NpyHalf* for all API functions. See appendix A for an explicit list of functions currently contained in include/halffloat.h. - Functionality will be identical to include/halffloat.h.but the interface will be inline with the existing C-API patterns and may not be a one to one copy of the interface present in include/halffloat.h. - All API functions will be added to code_generators/numpy_api.py beginning at location 369, and counting up. Versioning will be MinVersion("2.4"). With code_generators/cversions.txt updated with new hashing information. - The contents of npymath relevant to ensuring proper working of NpyHalf* will be ported and contained in the multiarray directory. - If I identify any shared functions used in include/halffloat.h that may assist in the removal of npymath static library altogether I'll contain the functions in a suitable header file. Error Handling and Semantics - Error handling will follow the normal NumPy conventions. - Current semantics, behavior of code that use include/halffloat.h will remain unchanged and continue to produce identical results. Documentation - New C-API documentation will be added as needed. - Documentation requiring include/halffloat.h and npymath will be updated with language that the new NpyHalf* functions are preferred. With additional language to require accessing import_array() for access to NpyHalf* API functionality. Testing and Benchmarking - A review of current tests seems to indicate a lack of float16 specific tests. I will develop and add tests to cover NpyHalf* functions. - Benchmarking will be completed so as not to unduly decrease performance. NumPy Internals Update - There are several internal self contained NumPy functions that point to include/halffloat.h and npymath. For the sake of completeness I will update and refactor these functions to the new API. Conclusion and Community Feedback - I'm planning to begin work on adding a new NumPy C-API file in the multiarray C extension directory as NpyHalf* soon. - I have posted this as issue #30280 <https://github.com/numpy/numpy/issues/30280>, in addition to this email. Any feedback is, as always, much appreciated. Appendix A - List of Functions in include/halffloat.h /* include/halffloat.h */ float npy_half_to_float(npy_half h);double npy_half_to_double(npy_half h);npy_half npy_float_to_half(float f);npy_half npy_double_to_half(double d);�/* Comparisons */int npy_half_eq(npy_half h1, npy_half h2);int npy_half_ne(npy_half h1, npy_half h2);int npy_half_le(npy_half h1, npy_half h2);int npy_half_lt(npy_half h1, npy_half h2);int npy_half_ge(npy_half h1, npy_half h2);int npy_half_gt(npy_half h1, npy_half h2);/* faster *_nonan variants for when you know h1 and h2 are not NaN */int npy_half_eq_nonan(npy_half h1, npy_half h2);int npy_half_lt_nonan(npy_half h1, npy_half h2);int npy_half_le_nonan(npy_half h1, npy_half h2);�/* Miscellaneous functions */int npy_half_iszero(npy_half h);int npy_half_isnan(npy_half h);int npy_half_isinf(npy_half h);int npy_half_isfinite(npy_half h);int npy_half_signbit(npy_half h);npy_half npy_half_copysign(npy_half x, npy_half y);npy_half npy_half_spacing(npy_half h);npy_half npy_half_nextafter(npy_half x, npy_half y);npy_half npy_half_divmod(npy_half x, npy_half y, npy_half *modulus); /* Bit-level conversions */npy_uint16 npy_floatbits_to_halfbits(npy_uint32 f);npy_uint16 npy_doublebits_to_halfbits(npy_uint64 d);npy_uint32 npy_halfbits_to_floatbits(npy_uint16 h);npy_uint64 npy_halfbits_to_doublebits(npy_uint16 h); -- Amelia Thurdekoos Staff Software Engineer, Quansight Quansight | Your Data Experts w: www.quansight.org <http://quansight.org/> e: athurdekoos(a)quansight.com <https://www.linkedin.com/company/quansight/> <https://www.instagram.com/quansightai/> <https://bsky.app/profile/quansight.com> <https://twitter.com/quansightai>

7 17

making numpy.org Plausible analytics public
by Inessa Pawson Dec. 3, 2025

Dec. 3, 2025

Hi, all! In 2022, after much research and discussion with the NumPy maintainers and active contributors, we replaced Google Analytics with Plausible, an open source lightweight alternative that doesn’t collect personal data and provides the option for self-hosting. A dashboard for numpy.org (the part that runs on Hugo) was set up on the Scientific Python Project server. For the past three years, insights derived from the available website traffic data have helped prioritize the efforts of the NumPy documentation and translation teams. To better understand user needs for the NumPy documentation (generated with Sphinx), this month, we also added a Plausible script to the numpy/numpy repository. We are now considering making the dashboards public so that the collected data is available to the broader contributor community. If you have any questions or concerns, please share your feedback by December 1st. -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

3 3

NumPy 2.4.x has been branched, main is open for 2.5 development.
by Charles R Harris Nov. 30, 2025

Nov. 30, 2025

Hi All, Heads up. Chuck

1 0

Introduce `__numpy_dtype__` protocol
by sebastian Nov. 24, 2025

Nov. 24, 2025

Hi all, A heads up, that I have a PR to introduce `__numpy_dtype__` as a protocol. Right now when NumPy coerces to a dtype (e.g. via `np.dtype()` or `dtype=...`) it checks for a `.dtype` attribute on the object and if that is a NumPy dtype the conversion succeeds. The problem with this two-fold: 1. Not all dtypes are NumPy dtypes. Right now a non-NumPy dtype can interoperate with NumPy by having a `dtype.dtype` attribute that is a NumPy dtype. But that seems awkward and may in some cases prevent the use of the dtype attribute for something more to the point. 2. While numpy prevents `np.dtype(numpy_array)`, some other array-like objects will be converted to a dtype, e.g.: np.array([1, 2, 3], dtype=pandas.Series([1, 2, 3])) works but should not. Switching to `__numpy_dtype__` allows us to disable this trap. Right now there is no semantic change, besides that downstream would be encouraged to implement `__numpy_dtype__` if they currently have a `dtype` attribute that interoperates with NumPy. (In the case of a pandas Series that might be to raise an error or just set it to `None` so that NumPy raises one.) To me this seems be uncontroversial, since using `.dtype` has problems and this gives us a way to move away from it and disambiguate these situations. Cheers, Sebastian

3 2

ENH: Add a non-circular shift function
by Carlos Martin Nov. 23, 2025

Nov. 23, 2025

Feature request: Add a non-circular shift function that is similar to [`numpy.roll`](https://numpy.org/doc/stable/reference/generated/numpy.roll.html) but, instead of wrapping elements around, replaces unoccupied entries with a specified fill value. Examples: ``` >>> import numpy as np >>> a = np.arange(1, 6) >>> a array([1, 2, 3, 4, 5]) >>> np.shifted(a, 2) array([0, 0, 1, 2, 3]) >>> np.shifted(a, -2) array([3, 4, 5, 0, 0]) >>> a = np.arange(1, 10).reshape((3, 3)) >>> a array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) >>> np.shifted(a, (1, -2), (0, 1)) array([[0, 0, 0], [3, 0, 0], [6, 0, 0]]) ``` Prior discussion: https://github.com/numpy/numpy/issues/26220 Pull request: https://github.com/numpy/numpy/pull/29389

1 1

NumPy 2.3.5 released
by Charles R Harris Nov. 16, 2025

Nov. 16, 2025

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 2.3.4. The NumPy 2.3.4 release is a patch release split between a number of maintenance updates and bug fixes. This release supports Python 3.11-3.14. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.3.5>; release notes and the changelog are available on Github <https://github.com/numpy/numpy/releases/tag/v2.3.5>. *Contributors* A total of 10 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Aaron Kollasch + - Charles Harris - Joren Hammudoglu - Matti Picus - Nathan Goldbaum - Rafael Laboissière + - Sayed Awad - Sebastian Berg - Warren Weckesser - Yasir Ashfaq + *Pull requests merged* A total of 16 pull requests were merged for this release. - #29979: MAINT: Prepare 2.3.x for further development - #30026: SIMD, BLD: Backport FPMATH mode on x86-32 and filter successor... - #30029: MAINT: Backport write_release.py - #30041: TYP: Various typing updates - #30059: BUG: Fix np.strings.slice if stop=None or start and stop >= len... - #30063: BUG: Fix np.strings.slice if start > stop - #30076: BUG: avoid negating INT_MIN in PyArray_Round implementation (#30071) - #30090: BUG: Fix resize when it contains references (#29970) - #30129: BLD: update scipy-openblas, use -Dpkg_config_path (#30049) - #30130: BUG: Avoid compilation error of wrapper file generated with SWIG... - #30157: BLD: use scipy-openblas 0.3.30.7 (#30132) - #30158: DOC: Remove nonexistent ``order`` parameter docs of ``ma.asanyarray``... - #30185: BUG: Fix check of PyMem_Calloc return value. (#30176) - #30217: DOC: fix links for newly rebuilt numpy-tutorials site - #30218: BUG: Fix build on s390x with clang (#30214) - #30237: ENH: Make FPE blas check a runtime check for all apple arm systems Cheers, Charles Harris

1 1