Our plans for NumPy 2.0 (blog edition)

As NumPy developers we have decided to work on a NumPy 2.0 release to replace the NumPy 1.x release at the beginning of 2024. We have met to discuss many of the high-level issues we wish to address on April 1st. Now that NumPy 1.25 is branched and soon to be released, we will start to adopt changing into the NumPy main branch.

What not to expect

We wish to stress that while there are many inconsistencies and changes that we are planning we do aim to scope that in a way that most NumPy will not be disrupted strongly. We all remember the transition issues that came with Python 3 and realize that it is vital that most downstream libraries will be able to adept their code easily to achieve compatibility with both NumPy 1.x and 2.x.

What to expect

On the other hand, as an old project, NumPy has inconsistencies, outdated API, and within the C-API a backwards compatibility guarantee that make some changes imossible to make without a major version increase.

We do expect that many downstream libraries will have to adapt to changes in NumPy, in general the 2.0 release is expected to be "big" compared to releases in the 1.x series.

Why now? What are concrete changes to expect?

Many of the changes we expect in NumPy 2.0 are changes which would have been nice to do for years, but have been elusive due to being difficult to deprecate. We wish to take this opportunity to make many of these.

More concretely, the biggest user-facing changes will probably be:

1. The adoption of NEP 50 which changes the way NumPy does promotion of scalars. The goal of this NEP is to increase consistency between NumPy scalars and arrays and remove any code paths where the value changed the dtype of the result. At the same time, the NEP tries to conserve the convenience that arr_float32 + 3.0 should return a float32 array.
2. A slightly more heavy handed evolution of the NumPy API and reorganization of the docs much of which is outlined in the NEP 52.
3. Change the default integer dtype to 64bit on 64bit windows. It is a common source of confusion that NumPy still defaults to 32bit integers on 64 bit windows.

These changes align with years-long wishes, but are timely now because of work done to allow full featured user DTypes and an effort to align behavior between different array-object implementing libraries guided by the work of the "Array API".

In general, we hope to include many lower impact changes which some users may need to adept to but that greatly simplify our API or enable future work.

Last, but not least NEP 53 proposes to evolve our C-API to simplify future improvements, one of which is already under way in enhancing np.errstate. Depending on the scope, we may introduce a numpy2_compat package to ensure NumPy 1.x and 2.0 remain compatible (when compiling against NumPy 2.0).

Overall, the aim is to evolve NumPy especially in areas where incremental improvements via warnings are hard and we welcome contributions that fit this aim.

While NumPy doesn't strictly follow semantic version, the major release signals that we plan these larger incompatible changes. On the other hand, we do want to stress that an the aim remains that most users should have a smooth transition and will hopefully not need to worry or even notice NumPy 2.0.

New goodies?

We expect the new DType API will be public in NumPy 2.0 so that new user or internal DTypes will happen soon. Also other goodies hopefully, but those are for later posts :).