Mailman 3 August 2026 - NumPy-Discussion

next NumPy community meeting - Wednesday, July 29th, 2026 at 18:00 UTC
by Inessa Pawson Sept. 6, 2026

Sept. 6, 2026

The next NumPy community meeting will be held this Wednesday, July 29th at 18:00 (6 pm) UTC. 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

2 4

NEP 58: A variable-width bytes DType
by Nathan Aug. 31, 2026

Aug. 31, 2026

Hi all, I just opened a PR to add NEP 58, which proposes a new variable-width dtype, corresponding to the python bytes type. See https://github.com/numpy/numpy/pull/32433. Per NEP 0, I've copied the NEP content up through "Usage and Impact". Please keep substantive comments about the NEP as a whole in this thread rather than in the github PR for the NEP text. However, please direct specific comments about the text to the PR. Thanks all for your ideas and input on this, -Nathan ===================================== NEP 58 — A variable-width bytes DType ===================================== :Author: Nathan Goldbaum :Status: Draft :Type: Standards Track :Created: 2026-08-25 Abstract -------- I propose ``ByteStringDType``, a variable-width bytes data type: the bytes sibling of ``StringDType`` (:ref:`NEP 55 <NEP55>`). It reuses StringDType's arena-backed storage, allocator, and missing-data machinery while * storing and returning Python :class:`bytes`, * supporting embedded and trailing NUL bytes by construction, and * exposing only operations meaningful on raw bytes. Text and bytes never promote or cast implicitly. The only conversion between ``StringDType`` and ``ByteStringDType`` is via the ``np.strings.encode``/``np.strings.decode`` pair. These gain a C UFunc implementation, along with the ability to add codec-aware variable-width loops mirroring :meth:`str.encode` and :meth:`bytes.decode`. A working prototype accompanies this NEP as its reference implementation. Motivation and scope -------------------- NumPy's only bytes data type is the fixed-width ``S`` dtype (``np.dtypes.BytesDType``, scalar ``np.bytes_``). Because ``S`` is null-padded, it cannot represent trailing NUL bytes:: >>> np.array([b"x\x00"])[0] b'x' This makes ``S`` unsuitable for generic byte streams such as binary record formats, encoded blobs, and network data. The truncation cannot be fixed in place: existing code relies on it, so reports have been closed as not planned since 2011 (NumPy `issue #2414 <https://github.com/numpy/numpy/issues/2414>`__; more recently `issue #25268 <https://github.com/numpy/numpy/issues/25268>`__, which loses the final byte of a SHA-256 digest). :ref:`NEP 55 <NEP55>` called this out, explicitly ruled a bytes/arbitrary-encoding dtype out of its scope, and listed an improved binary dtype as complementary future work. NumPy `issue #27701 <https://github.com/numpy/numpy/issues/27701>`__ is the open request for a StringDType equivalent for ``bytes``. This NEP proposes that dtype. Many downstream libraries fall back to object arrays of ``bytes`` wherever they carry variable-width binary data, giving up NumPy's flat memory layout and loop machinery. PyArrow materializes every Arrow binary column as an `object array of boxed bytes objects <https://github.com/apache/arrow/blob/118892700b95fdfa9a6b3e482a6e5399563f5d…>`_, and the reverse conversion from ``S`` has to guess each element's length with ``strnlen``, `truncating at the first NUL <https://github.com/apache/arrow/blob/118892700b95fdfa9a6b3e482a6e5399563f5d…>`_. The h5py library reads HDF5 variable-length byte strings `as object arrays <https://github.com/h5py/h5py/blob/821e503405b5e26a1333b28f2b6418d1a2f8c88a/…>`_. Zarr defines a first-class ``variable_length_bytes`` data type and `stores it in object arrays <https://github.com/zarr-developers/zarr-python/blob/20ba31e3e1142fae83b178d…>`_ for the same reason. Astropy holds FITS variable-length binary columns in object arrays and cannot round-trip fixed-width character columns without rewriting their padding (`astropy#11341 <https://github.com/astropy/astropy/issues/11341>`__). pandas inherits the ``S`` truncation for ``bytes`` columns (`pandas#58205 <https://github.com/pandas-dev/pandas/issues/58205>`__). In scope: * A variable-width, NUL-transparent bytes DType with the same operation *set* as fixed-width ``S`` (ASCII case folding and predicates, byte-indexed search/slice), the same missing-data support as StringDType, and casts to/from ``S``, void, and bool. * Explicit, codec-aware ``encode`` and ``decode`` ufuncs as the only text-to-bytes path for the variable-width pair. * As a structural side effect, StringDType's UTF-8 assumptions are identified and confined to a small encoding-specific surface of the implementation. Out of scope: * Changing how Python ``bytes`` values are inferred (``np.array([b"x"])`` stays fixed-width ``S``, as NEP 55 kept ``str`` inference at ``U``). * Exposing other encodings (latin-1, utf-16) as array dtypes. The encoding-specific surface identified here is a starting point for an encoding-parameterized StringDType, but that is a new user-facing semantic that would need its own proposal. Usage and impact ---------------- Because it uses the same representation and arena-backed storage as ``StringDType``, the new ``ByteStringDType`` supports embedded and trailing NUL bytes automatically: .. code-block:: python >>> import numpy as np >>> from numpy.dtypes import ByteStringDType >>> a = np.array([b"x\x00", b"a\x00b", b"\xff\xfe"], dtype=ByteStringDType()) >>> a[0] # trailing NULs survive b'x\x00' >>> a[1] # embedded NULs too b'a\x00b' >>> np.strings.str_len(a) # lengths are in bytes, length-explicit array([2, 3, 2]) >>> np.strings.find(a, b"\x00") array([ 1, 1, -1]) This dtype does not support the ``coerce`` argument that ``StringDType`` supports, so data that is not bytes will be rejected by ``np.array()``: .. code-block:: python >>> np.array(["text"], dtype=ByteStringDType()) Traceback (most recent call last): ... TypeError: ByteStringDType only allows bytes data, got an instance of 'str'; convert text to bytes explicitly with str.encode(encoding) Converting between ``StringDType`` and ``ByteStringDType`` happens through ``np.strings.encode`` and ``np.strings.decode``. While the ``encode`` default transitions (see :ref:`backward_compatibility`), the ByteStringDType result is requested explicitly: >>> s = np.array(["héllo"], dtype=np.dtypes.StringDType()) >>> b = np.strings.encode(s, "utf-8", dtype=ByteStringDType()) >>> np.strings.decode(b, "utf-8") array(['héllo'], dtype=StringDType()) .. _backward_compatibility: Backward compatibility ---------------------- There is only one major backward compatibility concern: dealing with ``np.strings.encode``. The function already exists and supports ``StringDType``, but sub-optimally in a manner that cannot perserve trailing NUL bytes. This presents some awkward backward compatibility concerns for this proposal. In the prototype branch, ``np.strings.encode`` emits a ``DeprecationWarning`` for StringDType input when the new ``dtype=`` argument is unspecified. Until the default flips to ByteStringDType in a later release, its behavior is otherwise unchanged: fixed-width ``S`` result, full codec and error-mode support, and 0-d arrays for 0-d input. See :ref:`encoding_decoding` for more detail and :ref:`open_questions` for whether this deprecation should happen.

3 6

next NumPy triage meeting - Wednesday, February 18th, 2026 at 18:00 UTC
by Inessa Pawson Aug. 30, 2026

Aug. 30, 2026

Our next triage meeting will be held this Wednesday, February 18th 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 13

next NumPy Optimization Team meeting - Monday, August 10th, 2026 at 17:00 UTC
by Inessa Pawson Aug. 28, 2026

Aug. 28, 2026

Hi, all! The next NumPy Optimization Team meeting will be held on Monday, August 10th at 17:00 (5 pm) 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 1

[ANN] CFP: SciPy India 2026 -- Dec 19-20 -- IIT Madras
by Agriya Khetarpal Aug. 28, 2026

Aug. 28, 2026

Hi all, I am pleased to announce the Call for Proposals for SciPy India 2026, the fourteenth edition of the convening of scientific computing and open source software enthusiasts in India. The conference will take place on 19-20 December 2026 at the Indian Institute of Technology Madras, Chennai, Tamil Nadu, India. Please submit your proposal at: https://cfp.scipy.in/scipy-india-2026/ The last date to submit is 19 October 2026, 23:59 IST. Session Types ------------- Talks 30-minute sessions on the conference day, 20 December Workshops 3-hour hands-on sessions on the workshops day, 19 December Posters on the conference day, only an abstract is needed Tracks ------ * General * Scientific computing in the sciences and engineering * Numerical, computational, and visualisation tools * AI, machine learning, and data-driven discovery * High-performance computing (HPC) * Reproducibility in research * Teaching, education, and outreach * Maintainers and community Please spread the word. I am happy to answer any questions on this thread. You can also write to info(a)scipy.in, or join the chat at https://zulip.scipy.in. Best, Agriya Khetarpal, On behalf of the SciPy India 2026 programme committee https://scipy.in/2026

1 0

Adding np.minmax to NumPy
by Iason Krommydas Aug. 26, 2026

Aug. 26, 2026

Hi all, I would like to let you know that in https://github.com/numpy/numpy/pull/32231, we are implementing a fused np.minmax implementation that uses the mechanism to register reduction loops to ufuncs added in https://github.com/numpy/numpy/pull/31816. The implementation includes optimizations such as loop unrolling and SIMD (similar to the ones np.min/max were already using). This obviously does not remove any actual computation as both min and max need to be computed but it does them in a single pass over the input array. We saw a 1.25x to a 2x improvement over consecutive min/max calls depending on the axis being reduced and the dtype (the 2x comes in the cases where the computation is mostly limited by reading from memory). This is a long requested feature for NumPy (see https://github.com/numpy/numpy/issues/9836 and https://stackoverflow.com/questions/12200580/numpy-function-for-simultaneou… for example) There are ~15 sites in NumPy and ~70 sites in SciPy where both min and max are computed consecutively and np.minmax can replace those. I'm just sending this email out to inform the community and to also welcome feedback if people think this is a bad idea or have thoughts to share. Cheers, Iason.

4 4

next NumPy New Contributors' Hour - Thursday, May 28th, 2026 at 10 pm UTC
by Inessa Pawson Aug. 17, 2026

Aug. 17, 2026

Our next New Contributors' Hour will be held this Thursday, May 28th 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 2

NumPy 2.5.2 released
by Charles R Harris Aug. 9, 2026

Aug. 9, 2026

Hi All, The NumPy 2.5.2 is a patch release that fixes bugs discovered after the 2.5.1 release. The big news is that it includes wheels for the newly released Python 3.15.0rc1. This release supports Python versions 3.12-3.15. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/2.5.2>; release notes and the changelog are available on Github <https://github.com/numpy/numpy/releases/tag/v2.5.2>. *Contributors* A total of 16 people contributed to this release. People with a \"+\" by their names contributed a patch for the first time. - Abhijeetsingh Meena + - Charalampos Stratakis - Charles Harris - Chris Ninham + - David Woods - Geonho + - Gopu Yeshwanth Reddy + - Iason Krommydas - Ijtihed Kilani - Jelle Zijlstra + - Joren Hammudoglu - Kumar Aditya - Mike Boyle - Nathan Goldbaum - Raghuveer Devulapalli - Sebastian Berg *Pull requests merged* A total of 28 pull requests were merged for this release. - #31864: MAINT: Prepare 2.5.x for further development - #31889: TYP: Backport multiple static typing fixes 1. - #31900: TST: add tests for stable ABI numpy extensions (#31822) - #31901: BUG: fix `StringDType` coerce flag in binary ufunc promotion\... - #31902: BLD: fix meson deprecation warnings (#31892) - #31921: TYP: Backport multiple typing fixes 2. - #31947: MAINT: Update x86-simd-sort subproject (5adb334 → fa944ef) (#31908) - #31949: BUG: fix crash on 32 bit systems using abi3t (#31771) - #31950: MNT: remove some obsolete string to bool workarounds (#31859) - #31952: BUG: centralized helper for output coerce and na_object in stringdtype\... - #31953: BUG: fix CPU feature env diagnostic buffer overruns (#31905) - #31954: BUG: restore ndarray.conjugate() for legacy user-defined dtypes\... - #31955: TYP: Avoid shadowed dtype annotations - #32077: MAINT: Update verdored-meson/meson to match main. - #32114: BUG: fix refcount leak on overlapping copyto with where=False - #32115: BUG: fix swallowed cast error in fancy indexing assignment (#31975) - #32116: BUG: Fix buffered iterator stride after removing multi-index - #32117: BUG: fix `np.fromiter` corruption when reusing a `StringDType`\... - #32119: BUG: add a special case for StringDType in np.isdtype (#32030) - #32121: BUG: reference leak in `simd_sequence_from_iterable` (#32038) - #32122: BUG: ensure lock is held when accessing or writing to RNG state\... - #32123: BUG: fully reset cached RNG state for non-MT19937 RNGs (#32062) - #32135: TYP: type capabilities max dimensions - #32158: BUG: avoid possible stack overflow in arraydescr_dealloc (#32133) - #32206: MAINT: Update cibuildwheel to v4.2.0 - #32214: MAINT: Skip limited_api tests on some platforms. - #32220: TYP: `isclose` shape-typing fix for 2d array-likes (#32205) - #32221: BUG: avoid segfaults when legacy copyswap slot is not defined\... Cheers, Charles Harris

1 0

New contribution policies to encourage human-to-human communication
by Nathan Aug. 4, 2026

Aug. 4, 2026

Hi all, Many open source communities are struggling with a flood of AI-assisted contributions and a lack of developer resources to properly review it all. NumPy is no exception and the maintainer community has been discussing how to adapt to this new world and keep developer attention focused on high-quality contributions. To that end, the NumPy maintainer community has decided to turn on the new GitHub setting limiting the number of pull requests open for review at once to a single pull request at a time from non-maintainers. Contributors can be added to the list of accounts allowed to open more non-draft pull requests at the discretion of the maintainer team. Additionally, Melissa Weber Mendonça volunteered to set up a new bot to help automate the process of closing low-quality and stale PRs. People with triage rights will be able to add a label. Melissa will write when she has set that up. We've decided to liberally add people to this list who show up to a regular community and triage meeting, which we alternate between every week on Wednesdays. See the community calendar <https://scientific-python.org/calendars/> for times. We are aware that the current meeting time is inconvenient for many time zones and Ganesh Katherisan has volunteered to organize and run a second meeting time that is more friendly to timezones in the eastern hemisphere. If you're interested in regularly attending this new meeting helping Ganesh make sure the meeting is a useful venue, please reach out to him ( ganesh3597(a)gmail.com). Ganesh will be sharing more details about this soon. If you're unable to or do not want to attend meetings, you can also reach out on our Slack community or on the mailing list. Just know that we are trying to ensure we are communicating with humans and not bots, so please write using your own words and do not copy-paste from an AI model. This isn't something we're doing lightly. It's something we feel we have to do to keep the project moving forward and allow maintainers to focus on work they are excited about rather than triaging PRs or completely ignoring the PR queue. -Nathan

1 0