[Numpy-discussion] Re: Road to NumPy 2.0

[Aaron Meurer]

On Fri, Jan 20, 2023 at 9:12 AM Tyler Reddy 
wrote:

> For NEP 47/array API standard, do we have a sense for how far off
> numpy.array_api is from passing a tagged version of the conformance test
> suite?
>

The test suite for 2021.12 effectively passes everywhere, except for a few
very small things which are either too hard or not worth wrapping around
(the most notable of these is that np.array_api.asarray(copy=False) raises
NotImplementedError because we are waiting for np.asarray() to implement
it). Work hasn't happened yet to update it to the 2022.12 version of the
standard that was recently tagged. That will mainly involve adding complex
numbers.

Of course, that's just numpy.array_api. numpy itself has many more
failures. The most impactful of those were discussed at
https://mail.python.org/archives/list/numpy-discussion@python.org/thread/TTZEUKXUICDHGTCX5EMR6DQTYOSDGRV7/#YKBWQ2AP76WYWAP6GFRYMPHZCKTC43KM
.

This is all likely to turn into a NEP at some point.

Can you do something like "import numpy.array_api as np" and then "export
> ARRAY_API_TESTS_MODULE=numpy"?
>

You just use ARRAY_API_TESTS_MODULE=numpy.array_api


> Probably not exactly that, but you likely know what I mean. I'm guessing
> someone has already checked this, but maybe posting a short summary of the
> current test suite result on the project board item would be nice.
> Incidentally, is there a short summary of how well the other major libs are
> doing with this suite somewhere?
>

There are plans to work on an array API reporting site, which would allow
different libraries to upload a report of compliance to a central
site, which would produce something similar to the "HTML browser
compliance" site you may have seen.

Aaron Meurer


> Would you turn that test suite on in a subset of the CI to enforce
> conformance moving forward when the time is right?
>
> On Sun, 15 Jan 2023 at 05:46, Ralf Gommers  wrote:
>
>>
>>
>> On Wed, Jan 11, 2023 at 1:59 PM Sebastian Berg <
>> sebast...@sipsolutions.net> wrote:
>>
>>> Hi all,
>>>
>>> as brought up many times, I would like to aim for a NumPy 2.0.  The
>>> current hope would be to release within the year and start adding small
>>> breaking changes soon, but hidden behind feature flags.  Similar to what is
>>> already the case for NEP 50
>>>  with `export
>>> NPY_PROMOTION_STATE=weak`.
>>>
>>> Below, is a draft version for a NEP, I have also created the
>>> corresponding project board on github.
>>> Clearly, especially specific changes will need more discussion, but
>>> there are some clearer bigger ones as well as small changes that are
>>> breaking but should be easy to adapt for.
>>>
>>> Thanks to Inessa and Ralf who helped draft and revise this!
>>>
>>
>> Thanks for drafting this proposal and leading this effort Sebastian!
>>
>> It seems like no one wants to be the first to reply here, so I'll try to
>> get us started:) My opinion has always been that NumPy 2.0 should be a
>> "major" thing, and either reserved for a needed ABI break or if we'd have
>> other compelling features or needs. It looks to me like we have now reached
>> that point. In particular, Sebastian as the main developer of new dtype and
>> ufunc internals features, seems to have reached the point where the need
>> for backwards compatibility in the C API is imposing too much of a burden.
>> Making that work easier is enough of a reason for me to be +1 on a NumPy
>> 2.0. After so many years, saying that it's fine to have a breaking release
>> to clean things up is very likely a good thing long term.
>>
>> With that need established, other important improvements that are already
>> in the pipeline and best done in a 2.0 release, like enabling NEP 50 and
>> Python API improvements, make the overall picture a compelling one.
>>
>> I also like the proposed logistics: any major change needs to land on a
>> roadmap for 2.0, and for that it needs to have two champions who commit to
>> getting it done. Not breaking our regular 6-monthly releases schedules
>> looks like a good plan. Having a feature flag for the 1.25.0 release (June)
>> and then making breaking changes the default in the July-December period
>> seems very reasonable.
>>
>> Cheers,
>> Ralf
>>
>>
>>
>>>
>>>
>>> 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.
>>>
>>>
>>> <#m_-2251458491041950985_m_-5453977658075525012_m_-4971028583323681657_Abstract>
>>> Abstract
>>> 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 

[Numpy-discussion] Re: Road to NumPy 2.0

[Tyler Reddy]

For NEP 47/array API standard, do we have a sense for how far off
numpy.array_api is from passing a tagged version of the conformance test
suite? Can you do something like "import numpy.array_api as np" and then
"export ARRAY_API_TESTS_MODULE=numpy"? Probably not exactly that, but you
likely know what I mean. I'm guessing someone has already checked this, but
maybe posting a short summary of the current test suite result on the
project board item would be nice. Incidentally, is there a short summary of
how well the other major libs are doing with this suite somewhere?

Would you turn that test suite on in a subset of the CI to enforce
conformance moving forward when the time is right?

On Sun, 15 Jan 2023 at 05:46, Ralf Gommers  wrote:

>
>
> On Wed, Jan 11, 2023 at 1:59 PM Sebastian Berg 
> wrote:
>
>> Hi all,
>>
>> as brought up many times, I would like to aim for a NumPy 2.0.  The
>> current hope would be to release within the year and start adding small
>> breaking changes soon, but hidden behind feature flags.  Similar to what is
>> already the case for NEP 50
>>  with `export
>> NPY_PROMOTION_STATE=weak`.
>>
>> Below, is a draft version for a NEP, I have also created the
>> corresponding project board on github.
>> Clearly, especially specific changes will need more discussion, but there
>> are some clearer bigger ones as well as small changes that are breaking but
>> should be easy to adapt for.
>>
>> Thanks to Inessa and Ralf who helped draft and revise this!
>>
>
> Thanks for drafting this proposal and leading this effort Sebastian!
>
> It seems like no one wants to be the first to reply here, so I'll try to
> get us started:) My opinion has always been that NumPy 2.0 should be a
> "major" thing, and either reserved for a needed ABI break or if we'd have
> other compelling features or needs. It looks to me like we have now reached
> that point. In particular, Sebastian as the main developer of new dtype and
> ufunc internals features, seems to have reached the point where the need
> for backwards compatibility in the C API is imposing too much of a burden.
> Making that work easier is enough of a reason for me to be +1 on a NumPy
> 2.0. After so many years, saying that it's fine to have a breaking release
> to clean things up is very likely a good thing long term.
>
> With that need established, other important improvements that are already
> in the pipeline and best done in a 2.0 release, like enabling NEP 50 and
> Python API improvements, make the overall picture a compelling one.
>
> I also like the proposed logistics: any major change needs to land on a
> roadmap for 2.0, and for that it needs to have two champions who commit to
> getting it done. Not breaking our regular 6-monthly releases schedules
> looks like a good plan. Having a feature flag for the 1.25.0 release (June)
> and then making breaking changes the default in the July-December period
> seems very reasonable.
>
> Cheers,
> Ralf
>
>
>
>>
>>
>> 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.
>>
>> <#m_-5453977658075525012_m_-4971028583323681657_Abstract>Abstract
>> 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.
>> <#m_-5453977658075525012_m_-4971028583323681657_Motivation-and-impact>Motivation
>> and impact
>> NumPy 2.0 release is required for fixing old bugs and modernizing NumPy’s
>> code base. It is not planned to be a “break the world release”. This means:
>>
>>- It must be possible to compile downstream packages to be compatible
>>with both new and old NumPy versions. However, the C-API is expected to be
>>broken. The path to achieve this compatibility will be defined as a *high
>>priority* project.
>>- The *majority* of users should not require code updates or such
>>updates should be very easy to do. Expert users are likely to notice
>>changes though.
>>- We accept that some NumPy users may not able to adopt NumPy 2.0
>>immediately or may have to wait until following releases for adoption.
>>
>> One should keep in mind that even bug fixes can break the code of a small
>> number of users.
>> <#m_-5453977658075525012_m_-4971028583323681657_Timeline>Timeline
>> NumPy 2.0 will be scheduled for release in Jan 2024. Projects and changes
>> should be proposed as soon as possible. We propose a NumPy team meeting
>> around April 2023 (details to be discussed) in order to finalize
>> high-impact projects and 

[Numpy-discussion] Re: Road to NumPy 2.0

[Ralf Gommers]

On Wed, Jan 11, 2023 at 1:59 PM Sebastian Berg 
wrote:

> Hi all,
>
> as brought up many times, I would like to aim for a NumPy 2.0.  The
> current hope would be to release within the year and start adding small
> breaking changes soon, but hidden behind feature flags.  Similar to what is
> already the case for NEP 50
>  with `export
> NPY_PROMOTION_STATE=weak`.
>
> Below, is a draft version for a NEP, I have also created the corresponding
> project board on github.
> Clearly, especially specific changes will need more discussion, but there
> are some clearer bigger ones as well as small changes that are breaking but
> should be easy to adapt for.
>
> Thanks to Inessa and Ralf who helped draft and revise this!
>

Thanks for drafting this proposal and leading this effort Sebastian!

It seems like no one wants to be the first to reply here, so I'll try to
get us started:) My opinion has always been that NumPy 2.0 should be a
"major" thing, and either reserved for a needed ABI break or if we'd have
other compelling features or needs. It looks to me like we have now reached
that point. In particular, Sebastian as the main developer of new dtype and
ufunc internals features, seems to have reached the point where the need
for backwards compatibility in the C API is imposing too much of a burden.
Making that work easier is enough of a reason for me to be +1 on a NumPy
2.0. After so many years, saying that it's fine to have a breaking release
to clean things up is very likely a good thing long term.

With that need established, other important improvements that are already
in the pipeline and best done in a 2.0 release, like enabling NEP 50 and
Python API improvements, make the overall picture a compelling one.

I also like the proposed logistics: any major change needs to land on a
roadmap for 2.0, and for that it needs to have two champions who commit to
getting it done. Not breaking our regular 6-monthly releases schedules
looks like a good plan. Having a feature flag for the 1.25.0 release (June)
and then making breaking changes the default in the July-December period
seems very reasonable.

Cheers,
Ralf



>
>
> 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.
>
> <#m_-4971028583323681657_Abstract>Abstract
> 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.
> <#m_-4971028583323681657_Motivation-and-impact>Motivation and impact
> NumPy 2.0 release is required for fixing old bugs and modernizing NumPy’s
> code base. It is not planned to be a “break the world release”. This means:
>
>- It must be possible to compile downstream packages to be compatible
>with both new and old NumPy versions. However, the C-API is expected to be
>broken. The path to achieve this compatibility will be defined as a *high
>priority* project.
>- The *majority* of users should not require code updates or such
>updates should be very easy to do. Expert users are likely to notice
>changes though.
>- We accept that some NumPy users may not able to adopt NumPy 2.0
>immediately or may have to wait until following releases for adoption.
>
> One should keep in mind that even bug fixes can break the code of a small
> number of users.
> <#m_-4971028583323681657_Timeline>Timeline
> NumPy 2.0 will be scheduled for release in Jan 2024. Projects and changes
> should be proposed as soon as possible. We propose a NumPy team meeting
> around April 2023 (details to be discussed) in order to finalize
> high-impact projects and review all candidate projects.
> Projects not proposed by this time may not be prioritized for a final 2.0
> release.
> Changes which can be implemented using a feature-flag are strongly
> encouraged as it simplifies keeping projects moving.
> <#m_-4971028583323681657_Project-selection-process>Project selection
> process
> To determine the scope of work for NumPy 2.0 release, we suggest
> introducing three categories of projects/proposals:
>
>1. *high*: proposal requires high visibility or may be critical for
>the NumPy 2.0 release,
>2. *normal*,
>3. *candidate*: changes which are in an early planning stage.
>
> High priority proposals will be listed explicitly in this NEP.
> A project board  will track all
> projects proposed for NumPy 2.0, distinguishing the category and progress.
> <#m_-4971028583323681657_Proposing-a-project-for-NumPy-20-release>Proposing
> a