Mailman 3 January 2026 - NumPy-Discussion

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

Feb. 7, 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 22

next NumPy New Contributors' Hour - Thursday, January 8th, 2026 at 10 pm UTC
by Inessa Pawson Feb. 2, 2026

Feb. 2, 2026

Our first New Contributors' Hour in 2026 will be held this Thursday, January 8th at 10 pm UTC. Stop by to ask questions, share your progress, 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 1

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

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

NEP 57: NumPy platform support
by Ralf Gommers Jan. 30, 2026

Jan. 30, 2026

Hi all, There are quite a few open requests for adding support for more platforms, either in CI or distributing wheels on PyPI. It seemed high time to define a support policy. Both for us to be able to make decisions and document a list of supported platforms, and for the people asking for support to understand how we think about this topic. The immediate trigger for this NEP was https://github.com/numpy/numpy/issues/22318 (request to support ppc64le wheels), however this is already long overdue and there are a number of open issues/PRs as well as known headaches or decisions we recently made, e.g. Windows arm64 and x86, and macOS x86-64. This is a rough draft that I put together in an hour or two, drawing primarily from PEP 11 and other recent write-ups (all linked under Discussion). I'd like to discuss the main principles first before spending more time on polishing the text. PR at https://github.com/numpy/numpy/pull/30748. Full text below: =============================== NEP 57 — NumPy platform support =============================== :Author: Ralf Gommers <ralf.gommers(a)gmail.com> :Status: Draft :Type: Process :Created: 2026-01-30 :Resolution: - .. note:: This NEP is drafted as a policy specific to NumPy rather than a SPEC for several reasons that are all project-specific: * it involves committing to a nontrivial amount of maintainer effort, * personal commitment from a maintainer may make the difference between a yes and a no of supporting a platform (e.g., NumPy supported PyPy for a long time because of the efforts of one maintainer) * support for a platform being possible at all may depend on features of the code base (e.g., NumPy supports 32-bit Python on Windows while SciPy does not because there's no suitable compiler toolchain for it) * the number of wheels depends on whether the Stable ABI can be used (NumPy is more performance-sensitive for small arrays, so can't use it) Abstract -------- This PEP documents how a platform - i.e., a specific operating system, CPU architecture and CPython interpreter - becomes supported in NumPy, what platforms are currently supported, and were supported in the (recent) past. Motivation and scope -------------------- *This policy is being drafted now because there is a lot of interest in extending the number of platforms NumPy supports through wheels in particular.* The scope of this NEP includes: - The definition of tiers of support for platforms by NumPy - Policies and decision making for moving a platform to a different tier Out of scope for this NEP are: - Binary distributions of NumPy outside of PyPI - Partial testing in CI (e.g., testing only SIMD-specific code under QEMU) - More detailed breakdowns of wheels and support matrices, like compiler flavor and minimum version, or the BLAS library that is used in the build. Support tiers ------------- *This section is inspired by PEP 11 (CPython platform support), although definitions are not matching, because NumPy is not nearly as large a project as CPython.* Platform support is broken down into tiers. Each tier comes with different requirements which lead to different promises being made about support. To be promoted to a tier, steering council support is required and is expected to be driven by team consensus. Demotion to a lower tier occurs when the requirements of the current tier are no longer met for a platform for an extended period of time based on the judgment of the steering council. For platforms which no longer meet the requirements of any tier by the middle of a new feature release cycle, an announcement will be made to warn the community of the pending removal of support for the platform. If the platform is not brought into line for at least one of the tiers by the first release candidate, it will be listed as unsupported in this NEP. General principles ~~~~~~~~~~~~~~~~~~ 1. Maintainer effort is expensive, and we collectively have limited bandwidth - hence platform support is strongly influenced by the willingness of one or more maintainers to put in that effort. - Maintainers are trusted by the whole team. We generally do not question *why* a maintainer is motivated to put in the effort. If they are being paid for their effort or doing it as part of their job, that is fine - however they should disclose this to the Steering Council, and indicate whether long-term support is conditional on their employment or contractor status for the support tiers that include releasing wheels to PyPI. *Rationale: releasing wheels to PyPI is a long-term commitment by the project as a whole, see the backwards compatibility section below.* 2. CI support with native runners for the platform is strongly preferred. Free is best, however decisions on paid CI are up to the Steering Council. Emulation for running the test suite (e.g., under QEMU) or self-hosted buildbots are slower and less reliable, hence not preferred. 3. There should be broad enough demand for support for the platform for the tiers that include releasing wheels to PyPI. - A previously used rule of thumb: >=0.5% of the user base should be on this platform. There may be reasons to deviate from this rule of thumb. 4. Adding a non-wheel CI job for a platform to the NumPy CI matrix is much cheaper, and easily reverted in case of problems. The bar for adding such jobs is low, and assessed on a case-by-case basis. 5. For all platforms in any supported tier: the relevant prerequisites in our dependencies have been met. E.g., build tools have support, and for wheels there is support in CPython, PyPI, cibuildwheel, manylinux, and ``scipy-openblas64`` or another easily-integrated BLAS library. 6. Decision making: - Moving a platform to a lower support tier must be discussed on the mailing list. - Moving a platform to a higher support tier this includes releasing wheels on PyPI for that platform must be discussed on the mailing list. - Adding an entry for a platform for an unsupported platform or one without wheels can be done on GitHub, assuming it's clear from the discussion that the relevant maintainers agree. Tier 1 ~~~~~~ - Must have regular CI support on GitHub or (exceptionally) through another well-integrated CI platform that the release team and steering council deem acceptable. - The NumPy team releases wheels on PyPI for this platform - CI failures (either regular CI or wheel build CI) block releases. - All maintainers developers are responsible to keep the ``main`` branch and wheel builds working. Tier 1 platforms: - Windows x86-64 - Windows arm64 - Windows x86 (32-bit Python: note this is shipped without BLAS, it's legacy) - Linux x86-64 (manylinux) - Linux aarch64 (manylinux) - macOS arm64 - macOS x86-64 (expected to move to unsupported by 2027/28 once the platform is dropped by GitHub) Tier 2 ~~~~~~ - Must have regular CI support, either as defined for Tier 1 or through a reliable self-hosted service. - The NumPy team releases wheels on PyPI for this platform - CI failures block releases. - Must have at least one maintainer who commits to take primary and long-term responsibility for keeping the ``main`` branch and wheel builds working. Tier 2 platforms: - Linux x86-64 (musllinux) - Linux aarch64 (musllinux) - Free-threaded CPython Tier 3 ~~~~~~ - Is supported as part of NumPy's regular CI setup for the ``main`` branch. CI support as defined for Tier 2. - No wheels are released on PyPI for this platform - CI failures block releases (skips may be applied a bit more liberally). - Must have at least one maintainer or a regular contributor trusted by the NumPy maintainers who commits to take responsibility for CI on the ``main`` branch working. Tier 3 platforms: - FreeBSD (note: runs on Cirrus CI) - Linux ppc64le (note: runs on IBM-provided self-hosted runners) - Emscripten/Pyodide Unsupported platforms ~~~~~~~~~~~~~~~~~~~~~ All platforms not listed in the above tiers are unsupported by the NumPy team. We do not develop and test on such platforms, and so cannot provide any promises that NumPy will work on them. However, the code base does include unsupported code – that is, code specific to unsupported platforms. Contributions in this area are welcome as long as they: - pose a minimal maintenance burden to the core team, and - benefit substantially more people than the contributor. Unsupported platforms (previously in a supported tier, may be an incomplete list): - PyPy - macOS ppc64, universal, universal2 - Linux i686 - Linux on IBM Z (s390x) Unsupported platforms (known interest in moving to a higher tier): - iOS - Android - RISC-V - WASI Backward compatibility ---------------------- Moving a platform to a lower tier of support is generally backwards compatible. The exception is stopping to release wheels on PyPI for a platform. That causes signifcant disruption for existing users on that platform. Their install commands (e.g., ``pip install numpy``) may stop working because if a new release no longer has wheels for the platform, by default ``pip`` will try to build from source rather than using a wheel from an older version of ``numpy``. Therefore, we should be very reluctant to drop wheels for any platform. Discussion ---------- - `ENH: Provide Windows ARM64 wheels (numpy#22530) < https://github.com/numpy/numpy/issues/22530>`__ - `Releasing PowerPC (ppc64le) wheels? (numpy#22318) < https://github.com/numpy/numpy/issues/22318>`__ - `MAINT: drop support for PyPy (numpy#30416) < https://github.com/numpy/numpy/issues/30416>`__ - `ENH: Build and distribute manylinux wheels for riscv64 < https://github.com/numpy/numpy/issues/30216>`__ - `BLD: Add support for building iOS wheels (numpy#28759) < https://github.com/numpy/numpy/pull/28759>`__ - `BLD: Add Android support <https://github.com/numpy/numpy/pull/30412>`__ - `ENH: WASI Build <https://github.com/numpy/numpy/issues/25859>`__ - `PEP 11 - CPython platform support <https://peps.python.org/pep-0011/>`__ - `Debian's supported architectures < https://wiki.debian.org/SupportedArchitectures>`__ - `Discussion about supported platforms for wheels (scientific-python issue/discussion (Nov 2025) < https://github.com/scientific-python/summit-2025-nov/issues/4>`__ - `What platforms should wheels be provided for by default? (Packaging Discourse thread, 2026) < https://discuss.python.org/t/what-platforms-should-wheels-be-provided-for-b… >`__ - `Expectations that projects provide ever more wheels (pypackaging-native) <https://pypackaging-native.github.io/meta-topics/user_expectations_wheels/ >`__

2 1

NumPy-QuadDType v1.0.0 released
by Swayam Singh Jan. 23, 2026

Jan. 23, 2026

Hi everyone, I'm happy to announce the release of *NumPy-QuadDType-v1.0.0*, a cross-platform 128-bit (quadruple precision) floating-point data type for NumPy. Release notes are available on GitHub: https://github.com/numpy/numpy-quaddtype/releases/tag/v1.0.0 *Highlights* - *Platform support*: Linux, macOS (Intel & Apple Silicon), and Windows; Python 3.11–3.14 including free-threading (GIL-free) builds; Big-endian architecture support; FMA-disable option for older x86-64 CPUs (Sandy Bridge era) - *New ufuncs*: `logaddexp2`, `floor_divide`, `float_power`, `fmod`, `divmod`, `fabs`, `heaviside`, `conj`/`conjugate`, `expm1`, `cbrt`, `hypot`, `degrees`/`rad2deg`, `radians`/`deg2rad`, `nextafter`, `spacing`, `modf`, `ldexp`, `frexp`, and all logical ufuncs - *Enhanced scalar support*: `is_integer`, `as_integer_ratio`, `imag`/`real` getters, buffer protocol, `__version__` attribute, and support for `np.bool`, arbitrary-length Python ints, bytes, and sequences - *Casting improvements*: `same_value` casting rule; `StringDType` array casting; fixed-length string casting; bytes array casting; improved inter-backend quad-to-quad fixes - *Type stubs*: Full static typing support - *Serialization*: Pickle and hash support - *Array functions*: `argmax`/`argmin` slots, `nonzero`, `scanfunc`/`fromstr`, and comparison promoter registration *Links* - *Repo*: https://github.com/numpy/numpy-quaddtype - *Documentation*: https://numpy.org/numpy-quaddtype/ - *PyPI*: https://pypi.org/project/numpy-quaddtype/ - *Conda-Forge*: https://anaconda.org/conda-forge/numpy_quaddtype *Contributors* GitHub usernames of contributors to this release: - @SwayamInSync - @juntyr - @ngoldbaum - @jorenham - @melissawm - @mhvk Cheers, Swayam Singh

2 1

New contributor looking for beginner-friendly issues
by Abubakr Nazriev Jan. 21, 2026

Jan. 21, 2026

Hello NumPy community, I’m new to contributing to NumPy and open source in general, and I’d like to get involved. I'm planning on setting up NumPy locally this week, and I’m looking to get started with beginner-friendly issues or areas where help is needed (documentation, tests, or small fixes). Any guidance would be appreciated. Thank you! Abubakr N

3 4

next NumPy triage meeting - Wednesday, January 21st, 2026 at 18:00 UTC
by Inessa Pawson Jan. 18, 2026

Jan. 18, 2026

Our next triage meeting will be held this Wednesday, January 21st at 18:00 (6 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… If there are PRs or issues you’d like us to review, please add GitHub links to them to the meeting agenda: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg -- Cheers, Inessa Inessa Pawson GitHub: inessapawson

1 0

NumPy <1.x with Python 3.14 is fundamentally broken
by Sebastian Berg Jan. 18, 2026

Jan. 18, 2026

Hi all, a small piece of information: NumPy 1.x was not released with support for Python 3.14. Most of the time, a too new Python versions (in recent past) just broke compilation. However, this time around optimization work together with the one bit of arcane optimization tricks in NumPy *will* cause silently incorrect results in most non-trivial code [1]. There are no releases to yank or upper bounds to set so I didn't think we can actually do anything about it. But this just came up again (this time in pandas). IThe only (new) idea I have would be to upload a Python 1.26 + Python 3.14 wheel that includes no code besides raising an error at install time. (Anyone who is running into issues is compiling NumPy from scratch, but I guess they would probably use the wheel first if available.) Cheers, Sebastian [1] May affect windows builds less badly, where NumPy doesn't do this trick, but what does it matter....

5 5

numpy-quaddtype now has its own repository
by Nathan Jan. 16, 2026

Jan. 16, 2026

Hi all, I want to let everyone know that development of numpy-quaddtype is now hosted at https://github.com/numpy/numpy-quaddtype instead of in the numpy-user-dtypes repository. There is also a set of documentation at https://numpy.org/numpy-quaddtype/. I'd like to congratulate Swayam Singh (@SwayamInSync) and Juniper Tyree (@juntyr) for doing the bulk of the work to move this effort forward. It's been a pleasure to work with both of you and I'm looking forward to continuing to improve things. Hopefully this can also serve as a template for other interested people out there to write their own data types outside numpy. -Nathan

2 1

RFC: Adding 'periodic' boundary support to numpy.gradient
by Renato Fuzaro Miotto Jan. 13, 2026

Jan. 13, 2026

Hello NumPy developers, I am writing to propose an enhancement to numpy.gradient to support periodic boundary conditions natively. While numpy.gradient is a foundational tool for numerical differentiation, it currently lacks a mechanism to handle periodic domains without requiring users to manually pad their arrays (e.g., via np.pad(mode='wrap')). I believe adding a periodic parameter (potentially a boolean or a tuple for multi-axis support) would be a significant addition for the following reasons: 1. Elimination of Boundary Noise: In physical simulations (CFD, acoustics, orbital mechanics), the current edge_order=1 or 2 logic introduces artificial numerical dissipation or "noise" at the boundaries because it drops to one-sided differences. For periodic systems, every point is an interior point, and a central difference should be maintained throughout. 2. Memory Efficiency: For large-scale datasets, manual padding creates unnecessary memory copies. Native support would allow us to compute the gradient at the edges using index wrapping, improving performance and reducing the memory footprint. 3. Consistency with the SciPy Stack: Other core tools like scipy.ndimage (via mode='wrap') and numpy.fft inherently assume periodicity. Adding this to numpy.gradient fills a logical gap, providing a consistent experience for users moving between spatial and frequency domain analysis. 4. Simplified Implementation: Paradoxically, for periodic axes, the internal logic for non-uniform spacing becomes simpler. We can avoid the complex second-order boundary coefficients (the a,b,c Lagrange terms for edges) and apply the interior central difference stencil globally by wrapping the coordinate distances and array values. Implementation Plan: I am envisioning an API such as np.gradient(f, ..., periodic=[True, False, True]). This would default to False to preserve backward compatibility. I have a background in numerical methods and am an active user of the library. If the steering council and moderators find this feature to be a valuable addition to the NumPy core, I am prepared to draft a NEP (if required) and submit a Pull Request with a full implementation, including unit tests for both uniform and non-uniform grids. I would love to hear your thoughts on whether this fits within the current roadmap for the library. Best regards, Renato Miotto https://github.com/rfmiotto

1 0