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 <ralf.gomm...@gmail.com> 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 >> <https://numpy.org/neps/nep-0050-scalar-promotion.html> 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 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_-5453977658075525012_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 <https://github.com/orgs/numpy/projects/9> will track >> all projects proposed for NumPy 2.0, distinguishing the category and >> progress. >> >> <#m_-5453977658075525012_m_-4971028583323681657_Proposing-a-project-for-NumPy-20-release>Proposing >> a project for NumPy 2.0 release >> To start a project, there is one important thing: Believe that your >> change makes NumPy better and commit to trying to make it happen. >> To have a proposal listed on the NumPy 2.0 project board, we require the >> following: >> >> - At least two champions for each proposal, one of whom must be a >> NumPy core developer or similar to one in standing. >> - A brief assessment of the anticipated impact on downstream and >> end-users. This means assessing how many users/what groups of users are >> affected and in what way. >> - Support by the NumPy community or Steering Council (ideally both). >> Positive feedback to your proposal on the NumPy mailing list is a strong >> indicator of the community support. >> >> If *any* of the above requirements are not met, proposals will be listed >> as “candidate”. NumPy maintainers will review “candidate” projects on a >> case by case basis. >> We suggest including a brief header in every proposal (issue or PR): >> >> * **Champions**: >> * **Severity**: How does it affect users? >> * **Affects**: Who/how many users does it affect? >> >> Any further details or adjustments shall be added on request. Large >> changes may require their own NEP when requested by a maintainer. >> As a *suggestion*, “affects” could be roughly guided by the number of >> users: *rare*, *limited*, *common*, and *ubiquitous*. While “severity” >> could be *minor*, *typical* (code update needed), *severe* (e.g. large >> change/difficult to find), *critical* (incorrect results or no clear >> path for fixing things). The two together can then be used as a basis >> for decision making and discussion. >> <#m_-5453977658075525012_m_-4971028583323681657_Scope-of-work>Scope of >> work >> <#m_-5453977658075525012_m_-4971028583323681657_High-priority-projects>*High >> priority projects* >> The projects in this section are considered high impact from the >> compatibility point of view. >> Unless otherwise noted, these are currently proposals, most of these >> changes have their own NEPs which should be accepted. >> <#m_-5453977658075525012_m_-4971028583323681657_Enable-breaking-the-C-API>Enable >> breaking the C-API >> NumPy needs to define a process for breaking C-API. This project does not >> define *what* is broke, this is done separately on a case-by-case basis. >> We simply assume that sufficient changes will be done to make this >> worthwhile. >> >> - *Status*: Planning >> - *Champion*: Matti Picus (?), Sebastian Berg (?) >> - *Severity*: Severe (for maintainers without a plan), typical for >> users >> - *Affects*: Library maintainers, some users >> - *Notes*: >> - Many users may have issues if pip installing a very new NumPy >> version without updating other libraries. We assume that this isn’t a >> common scenario and will mostly result in clear errors. >> - All libraries will have to be recompiled. The transition plan >> will ensure that libraries adhering to best practices will have an easy >> transition. >> >> *Note:* A full plan is still outstanding and may require its own NEP. >> >> <#m_-5453977658075525012_m_-4971028583323681657_Adopt-NEP-50>Adopt NEP 50 >> Adopting NEP 50 changes the promotion behavior of NumPy scalars by >> removing any value-based casting. Details for this change are discussed >> in :ref:NEP50. >> >> - *Status*: Largely implemented, but open for discussions and open >> questions to be addressed. >> - *Champion*: Sebastian Berg, … >> - *Severity*: High in rare cases, some results can change or memory >> can bloat. >> - *Affects*: Many users, but hopefully not most as one needs to use >> smaller than default precision types to be affected. >> >> >> <#m_-5453977658075525012_m_-4971028583323681657_A-thorough-cleanup-of-the-Python-API>A >> thorough cleanup of the Python API >> The NumPy API is quite messy, with many functions and aliases that are >> not recommended for use, namespaces that are private but missing >> underscores, inconsistencies in argument names, and more. Changes will >> include removing aliases and outdated functionality (including many things >> that have been doc-deprecated already), making namespaces private, and >> making function signatures more consistent. >> >> - *Status*: Needs a separate NEP, and deprecations in 1.25.0 for what >> can be deprecated in a sensible way. >> - *Champion*: Ralf Gommers, Stefan van der Walt, … >> - *Severity*: Medium. It is expected that a lot of projects and users >> will see some breakage, but also that code changes to more idiomatic usage >> will be straightforward and compatible with both numpy 1.X and 2.0 >> - *Affects*: Many users and downstream projects >> >> >> <#m_-5453977658075525012_m_-4971028583323681657_Add-array-API-standard-support-to-the-main-namespace>Add >> array API standard support to the main namespace >> The main reason NEP 47 >> <https://numpy.org/neps/nep-0047-array-api-standard.html#backward-compatibility> >> aimed for a separate numpy.array_api submodule rather than the main >> namespace is that casting rules differed too much. With NEP 50 (see above), >> that will be resolved in NumPy 2.0. Having NumPy be a superset of the array >> API standard will be a significant improvement for code portability to >> other libraries (CuPy, JAX, PyTorch, etc.) and thereby address one of the >> top user requests from the 2020 NumPy user survey >> <https://numpy.org/user-survey-2020/> (GPU support). See the >> numpy.array_api API docs >> <https://numpy.org/devdocs/reference/array_api.html#table-of-differences-between-numpy-array-api-and-numpy> >> for an overview of differences between it and the main namespace (the >> “strictness” ones are not applicable). >> >> - *Status*: separate NEP to be written. >> - *Champion*: Aaron Meurer, Ralf Gommers >> - *Severity*: Medium. Most impact of breaking changes is likely >> concentrated in a few widely used APIs (e.g., change semantics of >> copy=False keyword to actually mean “don’t copy” rather than “copy if >> needed”) >> - *Affects*: most users and downstream projects >> >> <#m_-5453977658075525012_m_-4971028583323681657_Other-projects>*Other >> projects* >> See the project board <https://github.com/orgs/numpy/projects/9>. >> _______________________________________________ >> NumPy-Discussion mailing list -- numpy-discussion@python.org >> To unsubscribe send an email to numpy-discussion-le...@python.org >> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ >> Member address: ralf.gomm...@googlemail.com >> > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: tyler.je.re...@gmail.com >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
