[Numpy-discussion] Re: NEP 29 and the faster Python release cadence

2022-05-26 Thread Matti Picus 

On 26/5/22 05:40, Aaron Meurer wrote:


We cannot do that (yet, at least). Failing to publish wheels for a supported 
Python version on a major OS is far worse than dropping support completely. 
This will remain true until the time that Pip starts defaulting to wheels-only 
and never picks the sdist if there's an older release for that platform + 
Python combo.

sounds like if even the latest version doesn't support a given CPython
version (and has CPython-versioned wheels), then pip installing it
will fail. Is that correct?



No. The problem is that if we do not provide binary wheels, pip 
installing Numpy will not fail. It will try to build from source. Even 
if this painfully and slowly succeeds, it means the user probably did 
not get the BLAS support they thought they were going to get. The 
situation for SciPy is similar but worse: it takes forever to build, and 
will probably likewise fail to build properly.



Matti

___
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: NEP 29 and the faster Python release cadence

2022-05-26 Thread Ralf Gommers 
On Thu, May 26, 2022 at 4:41 AM Aaron Meurer  wrote:

> > I have seen problems popping up already in a few places with latest
> numpy not supported what is still the most commonly used Python version
> (don't have links, sorry - but they were real packaging-related issues). So
> I don't think it makes sense to shorten the time window. I also don't think
> there's a need to drop one version that's urgent - it's some effort and CI
> time, but the balance is decent right now.
>
> It's hard to say the balance is decent right now if the faster cadence
> isn't even in full effect yet (as I noted in my original email).
>
> Generally I would say that dropping support only means that users of
> older versions would simply need to use an older version of the
> library.
>

That is not the full story unfortunately. The Python packaging tooling
(Pip, Poetry et al) is imperfect, so if other packages depend on NumPy and
then at install time a tool figures out that latest NumPy cannot be used,
or somewhere there's an upper bound in the version constraints explicitly,
some things tend to go wrong.


>
> > There was a lot of discussion around how big the window should be with
> 42mo being about in the middle of what people advocated for.  I am aware of
> institutions that are on an every-other Python upgrade pattern (py37 ->
> py39 -> (expected) py311) so always having at least 3 Pythons in the window
> is important.  Based on what we have seen so far, I still think 42mo is a
> good choice, but do not think we have seen it in operations long enough to
> draw any conclusions (the downside of year-scale planning is you need to
> wait years to see if it worked out like you expected!) and hence do not
> think we should make any changes to the time window for another few years.
>  That said, I am currently sympathetic to making the window longer and
> against making it shorter.
>
> The reason I brought this up is because we were looking at whether it
> makes sense to use NEP 29 for SymPy. Obviously we aren't bound to
> using it, but given this apparent discrepancy in the text (which still
> exists),


What discrepancy?

Cheers,
Ralf
___
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: Enhancement for AArch64 SVE instruction set

2022-05-26 Thread kawakami . k 
Thank you Gommers

I'd like to discuss this again when I finish SVE implementation. (It may be one 
month later.)

Cheers,
Kentaro
___
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: Enhancement for AArch64 SVE instruction set

2022-05-26 Thread Ralf Gommers 
On Thu, May 26, 2022 at 3:19 PM  wrote:

> Thank you Gommers
>
> I'd like to discuss this again when I finish SVE implementation. (It may
> be one month later.)
>

Sounds great, thanks Kentaro.

Cheers,
Ralf


> Cheers,
> Kentaro
> ___
> 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...@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

[Numpy-discussion] Re: NEP 29 and the faster Python release cadence

2022-05-26 Thread Thomas Caswell 
https://github.com/numpy/numpy/pull/21601 has been merged, but we should
make sure everyone is on board with the updated wording.  The intent was to
resolve the discrepancy I think Aaron is referring to (the text spoke of
the 18mo release cycle  in present tense) and to justify sticking with
42months despite the upstream change.

I think it is good for the overall community if we have a (mostly) unified
position on this, but if projects are going to disregard NEP 29 I am
personally happy for them to run faster :)

Tom

On Thu, May 26, 2022 at 7:08 AM Ralf Gommers  wrote:

>
>
> On Thu, May 26, 2022 at 4:41 AM Aaron Meurer  wrote:
>
>> > I have seen problems popping up already in a few places with latest
>> numpy not supported what is still the most commonly used Python version
>> (don't have links, sorry - but they were real packaging-related issues). So
>> I don't think it makes sense to shorten the time window. I also don't think
>> there's a need to drop one version that's urgent - it's some effort and CI
>> time, but the balance is decent right now.
>>
>> It's hard to say the balance is decent right now if the faster cadence
>> isn't even in full effect yet (as I noted in my original email).
>>
>> Generally I would say that dropping support only means that users of
>> older versions would simply need to use an older version of the
>> library.
>>
>
> That is not the full story unfortunately. The Python packaging tooling
> (Pip, Poetry et al) is imperfect, so if other packages depend on NumPy and
> then at install time a tool figures out that latest NumPy cannot be used,
> or somewhere there's an upper bound in the version constraints explicitly,
> some things tend to go wrong.
>
>
>>
>> > There was a lot of discussion around how big the window should be with
>> 42mo being about in the middle of what people advocated for.  I am aware of
>> institutions that are on an every-other Python upgrade pattern (py37 ->
>> py39 -> (expected) py311) so always having at least 3 Pythons in the window
>> is important.  Based on what we have seen so far, I still think 42mo is a
>> good choice, but do not think we have seen it in operations long enough to
>> draw any conclusions (the downside of year-scale planning is you need to
>> wait years to see if it worked out like you expected!) and hence do not
>> think we should make any changes to the time window for another few years.
>>  That said, I am currently sympathetic to making the window longer and
>> against making it shorter.
>>
>> The reason I brought this up is because we were looking at whether it
>> makes sense to use NEP 29 for SymPy. Obviously we aren't bound to
>> using it, but given this apparent discrepancy in the text (which still
>> exists),
>
>
> What discrepancy?
>
> Cheers,
> Ralf
>
> ___
> 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: tcasw...@gmail.com
>


-- 
Thomas Caswell
tcasw...@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

[Numpy-discussion] NumPy 1.23.0rc1 released

2022-05-26 Thread Charles R Harris 
Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.23.0rc1. The NumPy 1.23.0 release continues the ongoing work to improve
the handling and promotion of dtypes, increase the execution speed, clarify
the documentation, and expire old deprecations. The highlights are:


   - Implementation of ``loadtxt`` in C, greatly improving its performance.
   - Exposing DLPack at the Python level for easy data exchange.
   - Changes to the promotion and comparisons of structured dtypes.
   - Improvements to f2py.

The Python versions supported in this release are 3.8-3.10, 3.11 will be
supported when it comes out. Note that 32 bit wheels are only provided for
Windows, all other wheels are 64 bits on account of Ubuntu, Fedora, and
other Linux distributions dropping 32 bit support. All 64 bit wheels are
also linked with 64 bit OpenBLAS. Wheels can be downloaded from PyPI
; source archives, release
notes, and wheel hashes are available on Github
.

*Contributors*

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

   - @DWesl
   - @GalaxySnail +
   - @code-review-doctor +
   - @h-vetinari
   - Aaron Meurer
   - Alexander Shadchin
   - Alexandre de Siqueira
   - Allan Haldane
   - Amrit Krishnan
   - Andrei Batomunkuev
   - Andrew J. Hesford +
   - Andrew Murray +
   - Andrey Andreyevich Bienkowski +
   - André Elimelek de Weber +
   - Andy Wharton +
   - Arryan Singh
   - Arushi Sharma
   - Bas van Beek
   - Bharat Raghunathan
   - Bhavuk Kalra +
   - Brigitta Sipőcz
   - Brénainn Woodsend +
   - Burlen Loring +
   - Caio Agiani +
   - Charles Harris
   - Chiara Marmo
   - Cornelius Roemer +
   - Dahyun Kim +
   - Damien Caliste
   - David Prosin +
   - Denis Laxalde
   - Developer-Ecosystem-Engineering
   - Devin Shanahan +
   - Diego Wang +
   - Dimitri Papadopoulos Orfanos
   - Ding Liu +
   - Diwakar Gupta +
   - Don Kirkby +
   - Emma Simon +
   - Eric Wieser
   - Evan Miller +
   - Evgeni Burovski
   - Evgeny Posenitskiy +
   - Ewout ter Hoeven +
   - Felix Divo
   - Francesco Andreuzzi +
   - Ganesh Kathiresan
   - Gaëtan de Menten
   - Geoffrey Gunter +
   - Hans Meine
   - Harsh Mishra +
   - Henry Schreiner
   - Hood Chatham +
   - Ilhan Polat
   - Inessa Pawson
   - Isuru Fernando
   - Ivan Gonzalez +
   - Ivan Meleshko +
   - Ivan Yashchuk +
   - Janus Heide +
   - Jarrod Millman
   - Jason Thai +
   - Jeremy Volkman +
   - Jesús Carrete Montaña +
   - Jhong-Ken Chen (陳仲肯) +
   - John Kirkham
   - John-Mark Gurney +
   - Jonathan Deng +
   - Joseph Fox-Rabinovitz
   - Jouke Witteveen +
   - Junyan Ou +
   - Jérôme Richard +
   - Kassian Sun +
   - Kazuki Sakamoto +
   - Kenichi Maehashi
   - Kevin Sheppard
   - Kilian Lieret +
   - Kushal Beniwal +
   - Leo Singer
   - Logan Thomas +
   - Lorenzo Mammana +
   - Margret Pax
   - Mariusz Felisiak +
   - Markus Mohrhard +
   - Mars Lee
   - Marten van Kerkwijk
   - Masamichi Hosoda +
   - Matthew Barber
   - Matthew Brett
   - Matthias Bussonnier
   - Matthieu Darbois
   - Matti Picus
   - Melissa Weber Mendonça
   - Michael Burkhart +
   - Morteza Mirzai +
   - Motahhar Mokf +
   - Muataz Attaia +
   - Muhammad Motawe +
   - Mukulika Pahari
   - Márton Gunyhó +
   - Namami Shanker +
   - Nihaal Sangha +
   - Niyas Sait
   - Omid Rajaei +
   - Oscar Gustafsson +
   - Ovee Jawdekar +
   - P. L. Lim +
   - Pamphile Roy +
   - Pantelis Antonoudiou +
   - Pearu Peterson
   - Peter Andreas Entschev
   - Peter Hawkins
   - Pierre de Buyl
   - Pieter Eendebak +
   - Pradipta Ghosh +
   - Rafael Cardoso Fernandes Sousa +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Raphael Kruse
   - Raúl Montón Pinillos
   - Robert Kern
   - Rohit Goswami
   - Ross Barnowski
   - Ruben Garcia +
   - Sadie Louise Bartholomew +
   - Saswat Das +
   - Sayed Adel
   - Sebastian Berg
   - Serge Guelton
   - Simon Surland Andersen +
   - Siyabend Ürün +
   - Somasree Majumder +
   - Soumya +
   - Stefan van der Walt
   - Stefano Miccoli +
   - Stephan Hoyer
   - Stephen Worsley +
   - Tania Allard
   - Thomas Duvernay +
   - Thomas Green +
   - Thomas J. Fan
   - Thomas Li +
   - Tim Hoffmann
   - Ting Sun +
   - Tirth Patel
   - Toshiki Kataoka
   - Tyler Reddy
   - Warren Weckesser
   - Yang Hau
   - Yoon, Jee Seok +

Cheers,

Charles Harris
___
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: NEP 29 and the faster Python release cadence

2022-05-26 Thread Aaron Meurer 
On Thu, May 26, 2022 at 3:45 AM Matti Picus  wrote:

> On 26/5/22 05:40, Aaron Meurer wrote:
>
> >> We cannot do that (yet, at least). Failing to publish wheels for a
> supported Python version on a major OS is far worse than dropping support
> completely. This will remain true until the time that Pip starts defaulting
> to wheels-only and never picks the sdist if there's an older release for
> that platform + Python combo.
> > sounds like if even the latest version doesn't support a given CPython
> > version (and has CPython-versioned wheels), then pip installing it
> > will fail. Is that correct?
> >
>
> No. The problem is that if we do not provide binary wheels, pip
> installing Numpy will not fail. It will try to build from source. Even
> if this painfully and slowly succeeds, it means the user probably did
> not get the BLAS support they thought they were going to get. The
> situation for SciPy is similar but worse: it takes forever to build, and
> will probably likewise fail to build properly.
>

If Python version 3.X isn't supported, and that non-support means it
actually doesn't work, then it will fail. That is unless pip is smart
enough to install the most recent version of NumPy that does support that
version of Python (which would have wheels). Ralf made it sound like this
is what would happen, but doesn't pip have python_requires to avoid this?

Aaron Meurer


>
> Matti
>
> ___
> 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: asmeu...@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