It’s been exactly one year since I started my journey as a NumPy Fellow, and looking back, it has honestly been the best job I’ve ever had. My main goal for 2025 was to push the boundaries of static typing within the Scientific Python ecosystem. I’m happy to report that we didn’t just push the boundaries; we reshaped them.

Here is a high-level look at what we achieved, from making numpy fully type-checked to bridging the gap between scientific computing and the wider Python typing community.

NumPy is Now Fully Type-Checked#

One of the biggest wins this year is that NumPy is now fully type-checked. When I started, there were significant gaps between the runtime behavior and the typing stubs.

For example, I spent a lot of time integrating stubtest — a mypy tool that checks if stubs match the runtime — into the CI pipeline. For this I had to fix thousands (yes, thousands) of errors in the stubs. Now typing correctness is enforced by running stubtest and mypy on the stubs in CI, ensuring that technical debt doesn’t creep back in.

Crucially, NumPy is now largely compatible with the official Python typing specification. I helped drop support for Python 3.11 to update our stubs to use the modern PEP 695 syntax, making the codebase cleaner and more future-proof.

Besides static typing, since NumPy 2.4.0, all function- and class-signatures can now also be inspected at runtime using inspect.signature. This is a game-changer for runtime type-checkers like beartype and typeguard.

Over the past year I’ve made hundreds of contributions to NumPy, so there’s a good chance I’m forgetting some important achievements.

The Shape-Typing Frontier: NumType#

A massive part of my fellowship was dedicated to the “holy grail” of array typing: shape-typing. For this I had to rely on type-checker behavior that isn’t well-specified, and therefore subject to change. Using these typing acrobatics in NumPy would be too risky, so we decided to create a new project for this, called NumType.

When NumType is installed, your static type-checker will use its .pyi stubs instead of those bundled with NumPy. There are three main advantages to this:

1. Improved ufunc annotations.
2. Full support of the NEP 50 promotion rules for all scalars, exhaustively verified to be 100% accurate.
3. Experimental shape-typing with automatic static broadcasting types.

The “magic” types that enable the dtype promotion and shape-type broadcasting are currently only accessible from the private type-check-only _numtype API. But the plan is to eventually make these part of the public numtype API.

But before you drop everything to install NumType, note that it’s currently in alpha, so there’s no backwards-compatibility guarantee. However, if you do decide to use it and encounter an issue, be sure to complain about it in high definition at https://github.com/numpy/numtype/issues :)

Strengthening the Ecosystem: scipy-stubs and Beyond#

Typing NumPy is useless if the libraries built on top of it aren’t typed. A significant portion of my time went into scipy-stubs.

• We transferred ownership of scipy-stubs — which started as jorenham/scipy-stubs — to the official SciPy organization.
• scipy-stubs now covers the full SciPy API, and only uses Any when absolutely necessary.
• It has grown massively — it now contains over 72,000 lines of code (according to scc), making it the largest hand-written stubs-only Python package; even if you include typeshed’s standard library stubs (which currently counts 69,439 lines of code).
• We added runtime support for the generic types, including the sparse arrays, probability distributions, and interpolation classes.
• I helped large libraries such as pandas, jax, colour, and pyspark adopt scipy-stubs.

I also made sure to spread the love to other corners of the ecosystem by adding typing support to numpy-financial, numpy-stl, numpy-quaddtype, numexpr, and threadpoolctl.

Bridging Communities#

Perhaps the achievement I’m most proud of is the collaboration with the type-checker maintainers. Scientific Python has complex needs that often stretch the limits of Python’s type system.

Throughout the year, I discovered and investigated bugs in all five major type-checkers: mypy, pyright, basedpyright, pyrefly, and ty. Some of the mypy bugs I even managed to fix myself. We fixed critical bugs affecting NumPy users and improved analysis times.

I feel that this work has brought the Scientific Python community much closer to the Python Typing community. I’m incredibly grateful to the maintainers of these tools for their responsiveness and willingness to collaborate.

Wrapping Up#

This fellowship has been an absolute privilege, and I feel like I’ve made the most out of it. If you want to dive into the nitty-gritty details, you can find all of my activity on my GitHub profile (@jorenham), but for now, I’m just happy to have made those squiggly lines a bit more meaningful.

Thanks to everyone who made this possible, and type safe!

The NumPy team is excited to announce the appointment of Joren Hammudoglu (@jorenham) as the second NumPy Developer in Residence. For the second time, the project is in a position to use its project funds to pay for a full year of maintainer time through the NumPy Fellowship Program.

Joren has been the driving force behind the improvements in NumPy’s support for static typing since he started contributing in mid-2024. He has authored a lot of the improvements — from the annotations themselves to CI support and working towards fundamental design improvements like ndarray shape typing — and helps guide and integrate the work of other NumPy contributors in this area, and engages with upstream projects like MyPy and Pyright and the typing standards/PEP process to help move static typing support for the ecosystem as a whole forward. He also contributes widely to static typing support in the ecosystem, as the author of scipy-stubs, numtype and more.

The NumPy Steering Council sees Joren’s appointment to this role as both recognition of his contributions and expertise as well as an opportunity to continue improving NumPy’s static typing support — an area that few maintainers are knowledgeable about but a significant fraction of end users tends to care about a lot.

Joren’s role is for the calendar year 2025. Thanks to individual and corporate donations, as well as payments from Tidelift, NumPy has been able to fund another full-time position for one year, following the first such role held by Sayed Adel in 2023. The funds are still transparently administered on Open Collective.

Welcome aboard, Joren! We’re excited to see the impact of your work.

The NumPy team is excited to announce the launch of the NumPy Fellowship Program and the appointment of Sayed Adel (@seiko2plus) as the first NumPy Developer in Residence. This is a significant milestone in the history of the project: for the first time, NumPy is in a position to use its project funds to pay for a full year of maintainer time. We believe that this will be an impactful program that will contribute to NumPy’s long-term sustainability as a community-driven open source project.

Sayed has been making major contributions to NumPy since the start of 2020, in particular around computational performance. He is the main author of the NumPy SIMD architecture (NEP 38, docs), generously shared his knowledge of SIMD instructions with the core developer team, and helped integrate the work of various volunteer and industry contributors in this area. As a result, we’ve been able to expand support to multiple CPU architectures, integrating contributions from IBM, Intel, Apple, and others, none of which would have been possible without Sayed. Furthermore, when NumPy tentatively started using C++ in 2021, Sayed was one of the proponents of the move and helped with its implementation.

The NumPy Steering Council sees Sayed’s appointment to this role as both recognition of his past outstanding contributions as well as an opportunity to continue improving NumPy’s computational performance. In the next 12 months, we’d like to see Sayed focus on the following:

• SIMD code maintenance,
• code review of SIMD contributions from others,
• performance-related features,
• sharing SIMD and C++ expertise with the team and growing a NumPy sub-team around it,
• SIMD build system migration to Meson,
• and wherever else Sayed’s interests take him.

“I’m both happy and nervous: this is a great opportunity, but also a great responsibility,” said Sayed in response to his appointment.

The funds for the NumPy Fellowship Program come from a partnership with Tidelift and from individual donations. We sincerely thank both Tidelift and everyone who donated to the project—without you, this program would not be possible! We also acknowledge the CPython Developer-in-Residence and the Django Fellowship programs, which served as inspiration for this program.

Sayed officially starts as the NumPy Developer in Residence today, 1 December 2022. Already, we are thinking about opportunities beyond this first year: we imagine “in residence” roles that focus on developing, improving, and maintaining other parts of the NumPy project (e.g., documentation, website, translations, contributor experience, etc.). We look forward to this exciting new chapter of the NumPy contributor community and will keep you posted on our progress.