[Numpy-discussion] next NumPy triage meeting - May 15th, 2024 at 7 pm UTC

2024-05-12 Thread Inessa Pawson 
The next NumPy triage meeting will be held this Wednesday, May 15th at 7pm
UTC. This is a meeting where we synchronously triage prioritized PRs and
issues.
Join us via Zoom:
https://numfocus-org.zoom.us/j/82096749952?pwd=MW9oUmtKQ1c3a2gydGk1RTdYUUVXZz09
.
Everyone is welcome to attend and contribute to a conversation.
Please notify us of issues or PRs that you’d like to have reviewed by
adding a GitHub link to them in the meeting agenda:
https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg.

-- 
Cheers,
Inessa

Inessa Pawson
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] NumPy 2.0.0rc2 released

2024-05-12 Thread Charles R Harris 
Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.0rc2. NumPy 2.0.0 is the first major release since 2006. It is the
result of 11 months of development since the last feature release and is
the work of 198 contributors spread over 1041 pull requests. It contains a
large number of exciting new features as well as changes to both the Python
and C APIs.

This major release includes breaking changes that could not happen in a
regular minor (feature) release - including an ABI break, changes to type
promotion rules, and API changes which may not have been emitting
deprecation warnings in 1.26.x. Key documents related to how to adapt to
changes in NumPy 2.0 include:

   - The release notes on Github
   
   - The numpy-2-migration-guide
   
   - The numpy 2.0-specific advice in for downstream package authors
   

Highlights include:

   - A new variable-length string dtype, StringDType, and a new
   `numpy.strings` namespace with performant ufuncs for string operations.
   - Support for float32 and long double in all `numpy.fft` functions.
   - Support for the array API standard in the main numpy namespace.
   - MacOS Accelerate support and binary wheels for macOS >=14.
   - A new tracing and introspection API.
   - Performance improvements.
   - Python API improvements.
   - C API improvements.

This release supports Python 3.9-3.12. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.

*Contributors*

A total of 198 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - @Algorithmist-Girl +
   - @DWesl
   - @Illviljan
   - @ellaella12 +
   - @liang3zy22 +
   - @matoro +
   - @mcp292 +
   - @mykykh +
   - @pojaghi +
   - @pratiklp00 +
   - @stefan6419846 +
   - @undermyumbrella1 +
   - Aaron Meurer
   - Aditi Saluja +
   - Adrin Jalali +
   - Agriya Khetarpal +
   - Albert Steppi +
   - Alex Cabrera +
   - Alexander Grund
   - Andrea Bianchi +
   - Andreas Florath +
   - Andrew Ardill +
   - Andrew Ho +
   - Andrew Nelson
   - Andrey Rybakov +
   - Ankur Singh +
   - Anton Prosekin +
   - Antony Lee
   - Bas van Beek
   - Ben Woodruff +
   - Bharat Raghunathan
   - Bhavya Alekhya +
   - Brandon Smith +
   - Brian Walshe +
   - Brigitta Sipőcz
   - Brock Mendel
   - Carl Meyer +
   - Charles Bousseau +
   - Charles Harris
   - Chris Sidebottom
   - Christian Lorentzen
   - Christian Veenhuis
   - Christoph Reiter
   - Christopher Sidebottom
   - Clément Robert
   - Cédric Hannotier
   - D.J. Ramones +
   - DanShatford +
   - Daniel Li +
   - Daniel Vanzo
   - Daval Parmar
   - Developer-Ecosystem-Engineering
   - Dhruv Rawat +
   - Dimitri Papadopoulos Orfanos
   - Edward E
   - Edward Yang +
   - Eisuke Kawashima +
   - Eliah Kagan +
   - Élie Goudout +
   - Elliott Sales de Andrade
   - Emil Olszewski +
   - Emily Hunt +
   - Éric Piel +
   - Eric Wieser
   - Even Rouault +
   - Evgeni Burovski
   - Filipe Laíns +
   - Francisco Sousa +
   - Ganesh Kathiresan
   - Gonzalo Tornaría +
   - Hans Meine
   - Heberto Mayorquin +
   - Heinz-Alexander Fuetterer +
   - Hood Chatham
   - Hugo van Kemenade
   - Ivan A. Melnikov +
   - Jacob M. Casey +
   - Jake Lishman +
   - Jake VanderPlas
   - James Oliver +
   - Jan Wassenberg +
   - Janukan Sivajeyan +
   - Johann Rohwer +
   - Johannes Kaisinger +
   - John Muradeli +
   - Joris Van den Bossche
   - Kai Striega
   - Kevin Sheppard
   - Kevin Wu +
   - Khawaja Junaid +
   - Kit Lee +
   - Kristian Minchev +
   - Kristoffer Pedersen +
   - Kuan-Wei Chiu +
   - Lane Votapka +
   - Larry Bradley
   - Leo Singer
   - Liang Yan +
   - Linus Sommer +
   - Logan Thomas
   - Lucas Colley +
   - Lukas Geiger
   - Lysandros Nikolaou +
   - Maanas Arora +
   - Maharshi Basu +
   - Mahder Gebremedhin +
   - Marcel Bargull +
   - Mark Mentovai +
   - Mark Ryan +
   - Marten Henric van Kerkwijk +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matthew Barber
   - Matthias Bussonnier
   - Matthias Koeppe
   - Matthias Schaufelberger +
   - Matti Picus
   - Maxwell Aladago
   - Maya Anderson +
   - Melissa Weber Mendonça
   - Meng Xiangzhuo +
   - Michael Kiffer
   - Miki Watanabe (渡邉 美希)
   - Milan Curcic +
   - Miles Cranmer
   - Miro Hrončok +
   - Mohamed E. BRIKI +
   - Mohaned Qunaibit +
   - Mohit Kumar +
   - Muhammed Muhsin +
   - Mukulika Pahari
   - Munira Alduraibi +
   - Namami Shanker
   - Nathan Goldbaum
   - Nyakku Shigure +
   - Ola x Nilsson +
   - Olivier Mattelaer +
   - Omid Rajaei
   - Pablo Losada +
   - Pamphile Roy
   - Paul Reece +
   - Pedro Kaj Kjellerup Nacht +
   - Peiyuan Liu +
   - Peter Hawkins
   - Pierre
   - Piete

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

2024-05-12 Thread Gael Varoquaux 
On Fri, May 10, 2024 at 04:42:49PM +0200, Ralf Gommers wrote:
> It gets ever-easier to install new Python versions, with pyenv/conda/etc. The 
> "my single Python install comes from python.org and I'm using the same one 
> because I am afraid to upgrade" is much less of an issue than it was 10 years 
> ago. And it's caused mostly by users having knowledge gaps. So yes it can be 
> a pain for them, but they'll have to learn at some point anyway. Same for "my 
> old HPC cluster uses ..." - it's often an even older Python anyway, and 
> you'll have tons of reasons why you don't want your cluster-installed stack - 
> learn to use Spack or Conda, and you'll be much happier in the long run.

IMHO the view that its a tooling/knowledge gap problem is a bit disconnected of 
users. I meet many users who either 

1. cannot control the Python version they run, or even the base environment, 
because of company culture (decisions at company level on these constraints). 
Maybe upper management in completely misguided here, but then upper management 
must be targeted, and it is not clear at all that constraints on packages is 
the right way to do it, as they typically never run any code.

2. have environments with many dependencies that get in gridlocks of 
dependencies that cannot be mutually satisfied. For my own work it becomes 
increasingly frequent for me to spawn multiple environments that then talk to 
each others (eg via files) to work around these problems.



Problem 1 is probably something that user organizations should change, and we 
need to understand why they lock Python versions. It could be a QA issue, and 
this might reveal both a lack of good practices for QA (ie testing) but also 
the instability of the ecosystems that creates a fear of upgrade. We should not 
be too fast in dismissing these organizations as strife with bad practices that 
could easily be changed, as even tech-savy organizations (such as Google, I 
believe) run into these problems.

Problem 2 is not a problem solvable by users: it comes from the fact that 
dependency version windows are too narrow. Without broad windows on 
dependencies, the more dependencies one has, the more one gets into an 
impossible situation. For this last reason, I strongly advocate that packages, 
in particular core packages, try hard to be as permissible as reasonably 
possible on dependencies.

Cheers,

Gaël
___
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