[Numpy-discussion] next NumPy community meeting

[Inessa Pawson]

The next NumPy community meeting will be held this Wednesday, January 18th
at 19:00 (7 pm) UTC.
Join us via Zoom:
https://us06web.zoom.us/j/83278611437?pwd=ekhoLzlHRjdWc0NOY2FQM0NPemdkZz09
Everyone is welcome and encouraged to attend.
To add to the meeting agenda the topics you’d like to discuss, follow the
link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both
For the notes from the previous meeting, visit:
https://github.com/numpy/archive/blob/main/community_meetings/community-2023-01-04.md

-- 
Cheers,
Inessa

Inessa Pawson
Contributor Experience Lead | NumPy
https://numpy.org/
GitHub: inessapawson
___
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

[Numpy-discussion] Documentation team meeting - Monday 16 January at 4 PM UTC

[Mukulika Pahari]

Hi all!

Our next Documentation Team meeting will happen on *Monday, January 16* at
***4PM UTC***. We now alternate the meeting times to be a bit more
inclusive. This means that we'll have a meeting at 12pm UTC every 28 days,
and a meeting at 4pm UTC every 28 days.

All are welcome - you don't need to already be a contributor to join. If
you have questions or are curious about what we're doing, we'll be happy to
meet you!

If you wish to join on Zoom, use this (updated) link:

https://numfocus-org.zoom.us/j/85016474448?pwd=TWEvaWJ1SklyVEpwNXUrcHV1YmFJQ...

Here's the permanent hackmd document with the meeting notes (still being
updated):

https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg
https://www.google.com/url?q=https%3A%2F%2Fhackmd.io%2FoB_boakvRqKR-_2jRV-Qj...

Hope to see you around!

* You can also visit https://scientific-python.org/calendars to add the
NumPy community calendar as an .ics file to your preferred calendar
manager. *

Best wishes,
Mukulika
___
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

[Numpy-discussion] numpy.dtype.num consistent across versions and architecture?

[Dima Kogan]

Hi. This is an ABI stability and portability question.

Suppose I write a C program that uses the numerical values returned by
numpy.dtype.num to identify types, can these values be relied upon to be
consistent in future releases of numpy? I'm only talking about base
types like np.int32, np.float64 and such. What if this was about "int",
which doesn't have an explicit size defined?

Along the same lines, what about different architectures? What if I'm
cross-compiling: building for arm64 on an amd64 box, for example. On the
build machine (amd64) I would run the amd64 python to get values of
numpy.dtype.num, and use those to build arm64 code that would then talk
to the arm64 python. Can the numpy.dtype.num values be relied upon to be
consistent across architectures?

I'd like the answer to both questions to be "yes" :)

Thanks!
___
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

[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 pr