Mailman 3 November 2025 - NumPy-Discussion

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

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

Dec. 2, 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 11

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

Nov. 30, 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 17

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

next NumPy Optimization Team meeting - Monday, January 20th, 2025 at 5 pm UTC
by Inessa Pawson Nov. 28, 2025

Nov. 28, 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 14

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

next NumPy triage meeting - Wednesday, May 28th, 2025 at 5 pm UTC
by Inessa Pawson Nov. 22, 2025

Nov. 22, 2025

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 12

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

Change return type of sign(timedelta64)
by Warren Weckesser Nov. 13, 2025

Nov. 13, 2025

There's an issue from 2017 that I'm working on fixing: https://github.com/numpy/numpy/issues/8463. The issue is that currently, the `sign` ufunc applied to a `timedelta64` instance returns a `timedelta64` instance. This means that the `sign` function for this type does not satisfy the properties that one would expect. For example, one would expect that, in general, `sign(x) * abs(x) == x`. But this does not work for `timedelta64`: ``` In [35]: x = timedelta64(-123, 's') In [36]: sign(x) * abs(x) [...] UFuncTypeError: ufunc 'multiply' cannot use operands with types dtype('<m8[s]') and dtype('<m8[s]') ``` Also mentioned in that issue is that one would expect `sign(timedelta64(123, 's')) == sign(timedelta64(999, 'm'))`, but currently those have different values: ``` In [41]: sign(timedelta64(123, 's')) Out[41]: np.timedelta64(1,'s') In [42]: sign(timedelta64(999, 'm')) Out[42]: np.timedelta64(1,'m') ``` The first has the value 1 *second*, and the second has the value 1 *minute*, and those values are not equal. In fact, the sign should not have units. The first natural choice for the sign of a `timedelta64` would be an integer, either -1, 0, or 1. However, a `timedelta64` instance might also be `NaT`, and none of those values are correct in that case. Instead we can use floats, and return `nan` for `sign(timedelta64('NaT', 's'))`. So the possible values are -1.0, 0.0, 1.0 and nan. There is some discussion of this choice in https://github.com/numpy/numpy/issues/8463. This is implemented as a draft PR: https://github.com/numpy/numpy/pull/30194. For such a change, we would usually go through a deprecation cycle. In this case, we are proposing to simply make the change, for the following reasons: * We can't really see it leading to bad results for users; the numerical values are still mathematically the same[1]. * Only few people should notice the change (even among users). * Generally, a warning is more annoying than any transition path that we or a user might try to implement. There isn't a good way to provide a deprecation phase where the user can opt-in to the new behavior during the deprecation phase and get rid of the warning. One can also argue that this is "just" a bug fix, but the current behavior has been around for a long time, so that argument doesn't carry much weight. We would be sure to not merge this right before a major release. It should be in the main development branch long enough for any downstream libraries or users (at least those that test with the development branch) to adapt to the change, or for us to revert it if the impact is bigger than expected. What do you think? Warren ----- [1] Incidentally, we'll also fix the bug where `sign(timedelta64('NaT'))` incorrectly returns -1 (https://github.com/numpy/numpy/issues/29496).

1 0