# 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](https://numpy.org/neps/nep-0050-scalar-promotion.html) 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](https://numpy.org/neps/nep-0052-python-api-cleanup.html). 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](https://numpy.org/neps/nep-0041-improved-dtype-support.html) and an effort to align behavior between different array-object implementing libraries guided by the work of the ["Array API"](https://data-apis.org/array-api/latest/). 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](https://numpy.org/neps/nep-0053-c-abi-evolution.html) proposes to evolve our C-API to simplify future improvements, one of which is already under way in enhancing [`np.errstate`](https://github.com/numpy/numpy/pull/23936). 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 :).
Last changed by  
 
Sebastian Berg
729

Read more

C-API

Delete all old macro names.

12/1/2023
Road to NumPy 2.0

Note: This is a living document. We are prepared to modify it through continued dialogue with the community. Its acceptance indicates consensus on the process and timelines. Abstract The NumPy 2.0 release is an opportunity to make some complex changes for which a normal deprecation wouldn’t be viable as the user impact may be larger than is normally considered acceptable for a minor release. Yet, NumPy 2.0 is not meant to be a large breaking release. Most users should not need to worry about introduced changes. This document contains essential information about the work on NumPy 2.0 release. Motivation and impact

9/13/2023
The Road to NumPy 2.0 (informational NEP version)

:author: Sebastian Berg :author: Ralf Gommers :author: Inessa Pawson :author: don't be shy :) Actually, maybe we can even agree on adding "Steering council" or "on behalf of the steering council" Note: This is a living document. We plan to modify it through continued dialogue with the community. Its acceptance indicates consensus on the process and timelines.

6/3/2023
Notes on float precision dicussion

Might be good to have a brief summary: [name=rkern] Quite strongly opposed to sacrificing accuracy at least on sin/cos [name=mattip] Voiced opinion for reversion [name=Dan Allen (brookhaven national lab)] Tends towards it being too inaccurate; some scipy lecture note examples give surprising results for new-comers. (you can see that as a teaching opportunity, but...) [name=Jerome Kieffer] Is opposed (was already opposed to any adoption of "SVML" the last time around) [name=rgommers] Is open to reverting the sin/cos changes since they seem to be significantly more disruptive than other SIMD changes over the past years. But also wants to see an improved general accuracy-precision tradeoff methodology or framework, because the comments about always needing maximum accuracy (in general, not specifically for sin/cos) are too simplistic - it's always a tradeoff. Suggests a compile time flag (or inclusion in the disable-svml one), probably defaulting to off.[name=seberg] I agree with this! But, I am a bit disappointed in the amount of methodology we are given to work with by those who like the less precise versions. (I agree that full precision is a pipe-dream, though) [name=Matthew Brett] doesn't like less precise defaults, either. [name=tcaswell] prefers not to revert because compared to SVML the results are mainly different rather than worse. (suggesting the burden of proof should be reverted). Matplotlib dealt with the changes relatively easily.

6/2/2023
Read more from Sebastian Berg
Published on HackMD