I am much more of an "upgrade when there is a X.1" release kind of guy, so my hat off to those who will bravely be testing the version on my behalf.
I am much more of an "upgrade when there is a X.1" release kind of guy, so my hat off to those who will bravely be testing the version on my behalf.
One new interesting feature, though, is the support for string routines: https://numpy.org/devdocs/reference/routines.strings.html#mo...
Sounds almost like they're building a language inside a language.
That’s not true? Python string implementation is very optimized, probably have similar performance to C.
[1] - https://github.com/ashvardanian/StringZilla?tab=readme-ov-fi...
Strings are immutable, so no efficient truncation, concatenation, or modifications of any time, you're always reallocating.
There's no native support for a view of string, so operations like iteration over windows or ranges have to allocate or throw away all the string abstractions.
By nature of how the interpreter stores objects, Strings are always going to have an extra level of indirection compared to what you can do with a language like C.
Python strings have multiple potential underlying representations, and thus have some overhead for managing and dealing with those multiple representations without exposing those details to user code
They're not building a language. They're carefully adding a newly-in-demand feature to a mature, already-built language.
You may want to check out cupy
> arange’s start argument is positional-only
Even the new string dtype I expect would go unnoticed by half of users or more, because they won't be using it (because Numpy historically only had fixed-length strings and generally poor support for them) and so won't even think to try it. Pandas meanwhile has had a proper string dtype for a while, so anyone interested in doing serious work on strings in data frames / arrays would presumably be using Pandas anyway.
Most of the breaking changes are in long-deprecated oddball functions that I literally have never seen used in the wild, and in the internal parts that will be a headache for library developers.
The only change that a casual user might actually notice is the change in repr(np.float64(3.0)), from "3.0" to "np.float64(3.0)".