Changelog
### 1.25.0
```
The NumPy 1.25.0 release continues the ongoing work to improve the
handling and promotion of dtypes, increase the execution speed, and
clarify the documentation. There has also been work to prepare for the
future NumPy 2.0.0 release, resulting in a large number of new and
expired deprecation. Highlights are:
- Support for MUSL, there are now MUSL wheels.
- Support the Fujitsu C/C++ compiler.
- Object arrays are now supported in einsum
- Support for inplace matrix multiplication (`=`).
We will be releasing a NumPy 1.26 when Python 12 comes out. That is
needed because distutils has been dropped by Python 12 and we will be
switching to using meson for future builds. The next mainline release
will be NumPy 2.0.0. We plan that the 2.0 series will still support
downstream projects built against earlier versions of NumPy.
The Python versions supported in this release are 3.9-3.11.
Deprecations
- `np.core.MachAr` is deprecated. It is private API. In names defined
in `np.core` should generally be considered private.
([gh-22638](https://github.com/numpy/numpy/pull/22638))
- `np.finfo(None)` is deprecated.
([gh-23011](https://github.com/numpy/numpy/pull/23011))
- `np.round_` is deprecated. Use `np.round` instead.
([gh-23302](https://github.com/numpy/numpy/pull/23302))
- `np.product` is deprecated. Use `np.prod` instead.
([gh-23314](https://github.com/numpy/numpy/pull/23314))
- `np.cumproduct` is deprecated. Use `np.cumprod` instead.
([gh-23314](https://github.com/numpy/numpy/pull/23314))
- `np.sometrue` is deprecated. Use `np.any` instead.
([gh-23314](https://github.com/numpy/numpy/pull/23314))
- `np.alltrue` is deprecated. Use `np.all` instead.
([gh-23314](https://github.com/numpy/numpy/pull/23314))
- Only ndim-0 arrays are treated as scalars. NumPy used to treat all
arrays of size 1 (e.g., `np.array([3.14])`) as scalars. In the
future, this will be limited to arrays of ndim 0 (e.g.,
`np.array(3.14)`). The following expressions will report a
deprecation warning:
python
a = np.array([3.14])
float(a) better: a[0] to get the numpy.float or a.item()
b = np.array([[3.14]])
c = numpy.random.rand(10)
c[0] = b better: c[0] = b[0, 0]
([gh-10615](https://github.com/numpy/numpy/pull/10615))
- `numpy.find_common_type` is now deprecated and its use
should be replaced with either `numpy.result_type` or
`numpy.promote_types`. Most users leave the second
`scalar_types` argument to `find_common_type` as `[]` in which case
`np.result_type` and `np.promote_types` are both faster and more
robust. When not using `scalar_types` the main difference is that
the replacement intentionally converts non-native byte-order to
native byte order. Further, `find_common_type` returns `object`
dtype rather than failing promotion. This leads to differences when
the inputs are not all numeric. Importantly, this also happens for
e.g. timedelta/datetime for which NumPy promotion rules are
currently sometimes surprising.
When the `scalar_types` argument is not `[]` things are more
complicated. In most cases, using `np.result_type` and passing the
Python values `0`, `0.0`, or `0j` has the same result as using
`int`, `float`, or `complex` in `scalar_types`.
When `scalar_types` is constructed, `np.result_type` is the correct
replacement and it may be passed scalar values like
`np.float32(0.0)`. Passing values other than 0, may lead to
value-inspecting behavior (which `np.find_common_type` never used
and NEP 50 may change in the future). The main possible change in
behavior in this case, is when the array types are signed integers
and scalar types are unsigned.
If you are unsure about how to replace a use of `scalar_types` or
when non-numeric dtypes are likely, please do not hesitate to open a
NumPy issue to ask for help.
([gh-22539](https://github.com/numpy/numpy/pull/22539))
Expired deprecations
- `np.core.machar` and `np.finfo.machar` have been removed.
([gh-22638](https://github.com/numpy/numpy/pull/22638))
- `+arr` will now raise an error when the dtype is not numeric (and
positive is undefined).
([gh-22998](https://github.com/numpy/numpy/pull/22998))
- A sequence must now be passed into the stacking family of functions
(`stack`, `vstack`, `hstack`, `dstack` and `column_stack`).
([gh-23019](https://github.com/numpy/numpy/pull/23019))
- `np.clip` now defaults to same-kind casting. Falling back to unsafe
casting was deprecated in NumPy 1.17.
([gh-23403](https://github.com/numpy/numpy/pull/23403))
- `np.clip` will now propagate `np.nan` values passed as `min` or
`max`. Previously, a scalar NaN was usually ignored. This was
deprecated in NumPy 1.17.
([gh-23403](https://github.com/numpy/numpy/pull/23403))
- The `np.dual` submodule has been removed.
([gh-23480](https://github.com/numpy/numpy/pull/23480))
- NumPy now always ignores sequence behavior for an array-like
(defining one of the array protocols). (Deprecation started NumPy
1.20)
([gh-23660](https://github.com/numpy/numpy/pull/23660))
- The niche `FutureWarning` when casting to a subarray dtype in
`astype` or the array creation functions such as `asarray` is now
finalized. The behavior is now always the same as if the subarray
dtype was wrapped into a single field (which was the workaround,
previously). (FutureWarning since NumPy 1.20)
([gh-23666](https://github.com/numpy/numpy/pull/23666))
- `==` and `!=` warnings have been finalized. The `==` and `!=`
operators on arrays now always:
- raise errors that occur during comparisons such as when the
arrays have incompatible shapes
(`np.array([1, 2]) == np.array([1, 2, 3])`).
- return an array of all `True` or all `False` when values are
fundamentally not comparable (e.g. have different dtypes). An
example is `np.array(["a"]) == np.array([1])`.
This mimics the Python behavior of returning `False` and `True`
when comparing incompatible types like `"a" == 1` and
`"a" != 1`. For a long time these gave `DeprecationWarning` or
`FutureWarning`.
([gh-22707](https://github.com/numpy/numpy/pull/22707))
- Nose support has been removed. NumPy switched to using pytest in
2018 and nose has been unmaintained for many years. We have kept
NumPy\'s nose support to avoid breaking downstream projects who
might have been using it and not yet switched to pytest or some
other testing framework. With the arrival of Python 3.12, unpatched
nose will raise an error. It is time to move on.
*Decorators removed*:
- raises
- slow
- setastest
- skipif
- knownfailif
- deprecated
- parametrize
- \_needs_refcount
These are not to be confused with pytest versions with similar
names, e.g., pytest.mark.slow, pytest.mark.skipif,
pytest.mark.parametrize.
*Functions removed*:
- Tester
- import_nose
- run_module_suite
([gh-23041](https://github.com/numpy/numpy/pull/23041))
- The `numpy.testing.utils` shim has been removed. Importing from the
`numpy.testing.utils` shim has been deprecated since 2019, the shim
has now been removed. All imports should be made directly from
`numpy.testing`.
([gh-23060](https://github.com/numpy/numpy/pull/23060))
- The environment variable to disable dispatching has been removed.
Support for the `NUMPY_EXPERIMENTAL_ARRAY_FUNCTION` environment
variable has been removed. This variable disabled dispatching with
`__array_function__`.
([gh-23376](https://github.com/numpy/numpy/pull/23376))
- Support for `y=` as an alias of `out=` has been removed. The `fix`,
`isposinf` and `isneginf` functions allowed using `y=` as a
(deprecated) alias for `out=`. This is no longer supported.
([gh-23376](https://github.com/numpy/numpy/pull/23376))
Compatibility notes
- The `busday_count` method now correctly handles cases where the
`begindates` is later in time than the `enddates`. Previously, the
`enddates` was included, even though the documentation states it is
always excluded.
([gh-23229](https://github.com/numpy/numpy/pull/23229))
- When comparing datetimes and timedelta using `np.equal` or
`np.not_equal` numpy previously allowed the comparison with
`casting="unsafe"`. This operation now fails. Forcing the output
dtype using the `dtype` kwarg can make the operation succeed, but we
do not recommend it.
([gh-22707](https://github.com/numpy/numpy/pull/22707))
- When loading data from a file handle using `np.load`, if the handle
is at the end of file, as can happen when reading multiple arrays by
calling `np.load` repeatedly, numpy previously raised `ValueError`
if `allow_pickle=False`, and `OSError` if `allow_pickle=True`. Now
it raises `EOFError` instead, in both cases.
([gh-23105](https://github.com/numpy/numpy/pull/23105))
`np.pad` with `mode=wrap` pads with strict multiples of original data
Code based on earlier version of `pad` that uses `mode="wrap"` will
return different results when the padding size is larger than initial
array.
`np.pad` with `mode=wrap` now always fills the space with strict
multiples of original data even if the padding size is larger than the
initial array.
([gh-22575](https://github.com/numpy/numpy/pull/22575))
Cython `long_t` and `ulong_t` removed
`long_t` and `ulong_t` were aliases for `longlong_t` and `ulonglong_t`
and confusing (a remainder from of Python 2). This change may lead to
the errors:
'long_t' is not a type identifier
'ulong_t' is not a type identifier
We recommend use of bit-sized types such as `cnp.int64_t` or the use of
`cnp.intp_t` which is 32 bits on 32 bit systems and 64 bits on 64 bit
systems (this is most compatible with indexing). If C `long` is desired,
use plain `long` or `npy_long`. `cnp.int_t` is also `long` (NumPy\'s
default integer). However, `long` is 32 bit on 64 bit windows and we may
wish to adjust this even in NumPy. (Please do not hesitate to contact
NumPy developers if you are curious about this.)
([gh-22637](https://github.com/numpy/numpy/pull/22637))
Changed error message and type for bad `axes` argument to `ufunc`
The error message and type when a wrong `axes` value is passed to
`ufunc(..., axes=[...])` has changed. The message is now more
indicative of the problem, and if the value is mismatched an
`AxisError` will be raised. A `TypeError` will still be raised for
invalidinput types.
([gh-22675](https://github.com/numpy/numpy/pull/22675))
Array-likes that define `__array_ufunc__` can now override ufuncs if used as `where`
If the `where` keyword argument of a `numpy.ufunc`{.interpreted-text
role="class"} is a subclass of `numpy.ndarray`{.interpreted-text
role="class"} or is a duck type that defines
`numpy.class.__array_ufunc__`{.interpreted-text role="func"} it can
override the behavior of the ufunc using the same mechanism as the input
and output arguments. Note that for this to work properly, the
`where.__array_ufunc__` implementation will have to unwrap the `where`
argument to pass it into the default implementation of the `ufunc` or,
for `numpy.ndarray`{.interpreted-text role="class"} subclasses before
using `super().__array_ufunc__`.
([gh-23240](https://github.com/numpy/numpy/pull/23240))
By default, the exported NumPy C API is now compatible with NumPy 1.19
Starting with NumPy 1.25 when including NumPy headers, NumPy now
defaults to exposing a backwards compatible API. This means that by
default binaries such as wheels build against NumPy 1.25 will also work
with NumPy 1.16 because it has the same API version as NumPy 1.19 which
is the oldest NumPy version compatible with Python 3.9.
You can customize this behavior using:
define NPY_TARGET_VERSION NPY_1_22_API_VERSION
or the equivalent `-D` option to the compiler. For more details please
see `for-downstream-package-authors`{.interpreted-text role="ref"}. A
change should only be required in rare cases when a package relies on
newly added C-API.
([gh-23528](https://github.com/numpy/numpy/pull/23528))
New Features
`np.einsum` now accepts arrays with `object` dtype
The code path will call python operators on object dtype arrays, much
like `np.dot` and `np.matmul`.
([gh-18053](https://github.com/numpy/numpy/pull/18053))
Add support for inplace matrix multiplication
It is now possible to perform inplace matrix multiplication via the `=`
operator.
python
>>> import numpy as np
>>> a = np.arange(6).reshape(3, 2)
>>> print(a)
[[0 1]
[2 3]
[4 5]]
>>> b = np.ones((2, 2), dtype=int)
>>> a = b
>>> print(a)
[[1 1]
[5 5]
[9 9]]
([gh-21120](https://github.com/numpy/numpy/pull/21120))
Added `NPY_ENABLE_CPU_FEATURES` environment variable
Users may now choose to enable only a subset of the built CPU features
at runtime by specifying the `NPY_ENABLE_CPU_FEATURES`
environment variable. Note that these specified features must be outside
the baseline, since those are always assumed. Errors will be raised if
attempting to enable a feature that is either not supported by your CPU,
or that NumPy was not built with.
([gh-22137](https://github.com/numpy/numpy/pull/22137))
NumPy now has an `np.exceptions` namespace
NumPy now has a dedicated namespace making most exceptions and warnings
available. All of these remain available in the main namespace, although
some may be moved slowly in the future. The main reason for this is to
increase discoverability and add future exceptions.
([gh-22644](https://github.com/numpy/numpy/pull/22644))
`np.linalg` functions return NamedTuples
`np.linalg` functions that return tuples now return namedtuples. These
functions are `eig()`, `eigh()`, `qr()`, `slogdet()`, and `svd()`. The
return type is unchanged in instances where these functions return
non-tuples with certain keyword arguments (like
`svd(compute_uv=False)`).
([gh-22786](https://github.com/numpy/numpy/pull/22786))
String functions in `np.char` are compatible with NEP 42 custom dtypes
Custom dtypes that represent unicode strings or byte strings can now be
passed to the string functions in `np.char`.
([gh-22863](https://github.com/numpy/numpy/pull/22863))
String dtype instances can be created from the string abstract dtype classes
It is now possible to create a string dtype instance with a size without
using the string name of the dtype. For example,
`type(np.dtype('U'))(8)` will create a dtype that is equivalent to
`np.dtype('U8')`. This feature is most useful when writing generic code
dealing with string dtype classes.
([gh-22963](https://github.com/numpy/numpy/pull/22963))
Fujitsu C/C++ compiler is now supported
Support for Fujitsu compiler has been added. To build with Fujitsu
compiler, run:
> python setup.py build -c fujitsu
SSL2 is now supported
Support for SSL2 has been added. SSL2 is a library that provides
OpenBLAS compatible GEMM functions. To enable SSL2, it need to edit
site.cfg and build with Fujitsu compiler. See site.cfg.example.
([gh-22982](https://github.com/numpy/numpy/pull/22982))
Improvements
`NDArrayOperatorsMixin` specifies that it has no `__slots__`
The `NDArrayOperatorsMixin` class now specifies that it contains no
`__slots__`, ensuring that subclasses can now make use of this feature
in Python.
([gh-23113](https://github.com/numpy/numpy/pull/23113))
Fix power of complex zero
`np.power` now returns a different result for `0^{non-zero}` for complex
numbers. Note that the value is only defined when the real part of the
exponent is larger than zero. Previously, NaN was returned unless the
imaginary part was strictly zero. The return value is either `0+0j` or
`0-0j`.
([gh-18535](https://github.com/numpy/numpy/pull/18535))
New `DTypePromotionError`
NumPy now has a new `DTypePromotionError` which is used when two dtypes
cannot be promoted to a common one, for example:
np.result_type("M8[s]", np.complex128)
raises this new exception.
([gh-22707](https://github.com/numpy/numpy/pull/22707))
`np.show_config` uses information from Meson
Build and system information now contains information from Meson.
`np.show_config` now has a new optional parameter `mode` to
help customize the output.
([gh-22769](https://github.com/numpy/numpy/pull/22769))
Fix `np.ma.diff` not preserving the mask when called with arguments prepend/append.
Calling `np.ma.diff` with arguments prepend and/or append now returns a
`MaskedArray` with the input mask preserved.
Previously, a `MaskedArray` without the mask was returned.
([gh-22776](https://github.com/numpy/numpy/pull/22776))
Corrected error handling for NumPy C-API in Cython
Many NumPy C functions defined for use in Cython were lacking the
correct error indicator like `except -1` or `except *`. These have now
been added.
([gh-22997](https://github.com/numpy/numpy/pull/22997))
Ability to directly spawn random number generators
`numpy.random.Generator.spawn` now allows to directly spawn new independent
child generators via the `numpy.random.SeedSequence.spawn` mechanism.
`numpy.random.BitGenerator.spawn` does the same for the underlying bit
generator.
Additionally, `numpy.random.BitGenerator.seed_seq` now gives
direct access to the seed sequence used for initializing the bit
generator. This allows for example:
seed = 0x2e09b90939db40c400f8f22dae617151
rng = np.random.default_rng(seed)
child_rng1, child_rng2 = rng.spawn(2)
safely use rng, child_rng1, and child_rng2
Previously, this was hard to do without passing the `SeedSequence`
explicitly. Please see `numpy.random.SeedSequence` for more
information.
([gh-23195](https://github.com/numpy/numpy/pull/23195))
`numpy.logspace` now supports a non-scalar `base` argument
The `base` argument of `numpy.logspace` can now be array-like if it is
broadcastable against the `start` and `stop` arguments.
([gh-23275](https://github.com/numpy/numpy/pull/23275))
`np.ma.dot()` now supports for non-2d arrays
Previously `np.ma.dot()` only worked if `a` and `b` were both 2d. Now it
works for non-2d arrays as well as `np.dot()`.
([gh-23322](https://github.com/numpy/numpy/pull/23322))
Explicitly show keys of .npz file in repr
`NpzFile` shows keys of loaded .npz file when printed.
python
>>> npzfile = np.load('arr.npz')
>>> npzfile
NpzFile 'arr.npz' with keys arr_0, arr_1, arr_2, arr_3, arr_4...
([gh-23357](https://github.com/numpy/numpy/pull/23357))
NumPy now exposes DType classes in `np.dtypes`
The new `numpy.dtypes` module now exposes DType classes and will contain
future dtype related functionality. Most users should have no need to
use these classes directly.
([gh-23358](https://github.com/numpy/numpy/pull/23358))
Drop dtype metadata before saving in .npy or .npz files
Currently, a `*.npy` file containing a table with a dtype with metadata cannot
be read back. Now, `np.save` and `np.savez` drop metadata before saving.
([gh-23371](https://github.com/numpy/numpy/pull/23371))
`numpy.lib.recfunctions.structured_to_unstructured` returns views in more cases
`structured_to_unstructured` now returns a view, if the stride between
the fields is constant. Prior, padding between the fields or a reversed
field would lead to a copy. This change only applies to `ndarray`,
`memmap` and `recarray`. For all other array subclasses, the behavior
remains unchanged.
([gh-23652](https://github.com/numpy/numpy/pull/23652))
Signed and unsigned integers always compare correctly
When `uint64` and `int64` are mixed in NumPy, NumPy typically promotes
both to `float64`. This behavior may be argued about but is confusing
for comparisons `==`, `<=`, since the results returned can be incorrect
but the conversion is hidden since the result is a boolean. NumPy will
now return the correct results for these by avoiding the cast to float.
([gh-23713](https://github.com/numpy/numpy/pull/23713))
Performance improvements and changes
Faster `np.sort` on AVX-512 enabled processors
Quicksort for 16-bit and 64-bit dtypes gain up to 15x and 9x speed up on
processors that support AVX-512 instruction set.
Thanks to [Intel corporation](https://open.intel.com/) for sponsoring
this work.
([gh-22315](https://github.com/numpy/numpy/pull/22315))
`__array_function__` machinery is now much faster
The overhead of the majority of functions in NumPy is now smaller
especially when keyword arguments are used. This change significantly
speeds up many simple function calls.
([gh-23020](https://github.com/numpy/numpy/pull/23020))
`ufunc.at` can be much faster
Generic `ufunc.at` can be up to 9x faster. The conditions for this
speedup:
- operands are aligned
- no casting
If ufuncs with appropriate indexed loops on 1d arguments with the above
conditions, `ufunc.at` can be up to 60x faster (an additional 7x
speedup). Appropriate indexed loops have been added to `add`,
`subtract`, `multiply`, `floor_divide`, `maximum`, `minimum`, `fmax`,
and `fmin`.
The internal logic is similar to the logic used for regular ufuncs,
which also have fast paths.
Thanks to the [D. E. Shaw group](https://deshaw.com/) for sponsoring
this work.
([gh-23136](https://github.com/numpy/numpy/pull/23136))
Faster membership test on `NpzFile`
Membership test on `NpzFile` will no longer decompress the archive if it
is successful.
([gh-23661](https://github.com/numpy/numpy/pull/23661))
Changes
`np.r_[]` and `np.c_[]` with certain scalar values
In rare cases, using mainly `np.r_` with scalars can lead to different
results. The main potential changes are highlighted by the following:
>>> np.r_[np.arange(5, dtype=np.uint8), -1].dtype
int16 rather than the default integer (int64 or int32)
>>> np.r_[np.arange(5, dtype=np.int8), 255]
array([ 0, 1, 2, 3, 4, 255], dtype=int16)
Where the second example returned:
array([ 0, 1, 2, 3, 4, -1], dtype=int8)
The first one is due to a signed integer scalar with an unsigned integer
array, while the second is due to `255` not fitting into `int8` and
NumPy currently inspecting values to make this work. (Note that the
second example is expected to change in the future due to
`NEP 50 <NEP50>`{.interpreted-text role="ref"}; it will then raise an
error.)
([gh-22539](https://github.com/numpy/numpy/pull/22539))
Most NumPy functions are wrapped into a C-callable
To speed up the `__array_function__` dispatching, most NumPy functions
are now wrapped into C-callables and are not proper Python functions or
C methods. They still look and feel the same as before (like a Python
function), and this should only improve performance and user experience
(cleaner tracebacks). However, please inform the NumPy developers if
this change confuses your program for some reason.
([gh-23020](https://github.com/numpy/numpy/pull/23020))
C++ standard library usage
NumPy builds now depend on the C++ standard library, because the
`numpy.core._multiarray_umath` extension is linked with the C++ linker.
([gh-23601](https://github.com/numpy/numpy/pull/23601))
Checksums
MD5
fbbc825509a7c07b510670d28ef8bbfa numpy-1.25.0rc1-cp310-cp310-macosx_10_9_x86_64.whl
4e180a777fb108729c5899f5d0dd809c numpy-1.25.0rc1-cp310-cp310-macosx_11_0_arm64.whl
d21d3e363c6e3ecef94a3cc9a014bd40 numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
3d0d215ea9f1c0bcf2544133cfae4e60 numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
fc7b40a9a38825e7065a3f68403870f1 numpy-1.25.0rc1-cp310-cp310-musllinux_1_1_x86_64.whl
b8277ceaf6893fa15cbfc550c23d0b87 numpy-1.25.0rc1-cp310-cp310-win32.whl
06018e514aea30f8bf533cdb05536e1f numpy-1.25.0rc1-cp310-cp310-win_amd64.whl
c74a294da0fbb44f3cf625527448ced7 numpy-1.25.0rc1-cp311-cp311-macosx_10_9_x86_64.whl
342eaeed6ba93fe58fcf0c70ed4df191 numpy-1.25.0rc1-cp311-cp311-macosx_11_0_arm64.whl
43c70b2d9fedd62053b9c5aac254eed2 numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
eedfedfd3b08cce4969a5688bc11217d numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
a97d41371f7a9b71be54091868c907ce numpy-1.25.0rc1-cp311-cp311-musllinux_1_1_x86_64.whl
9f23c161c940c2d5c88f6f2a96947edd numpy-1.25.0rc1-cp311-cp311-win32.whl
316c96a7a991af57a3956be3f070856b numpy-1.25.0rc1-cp311-cp311-win_amd64.whl
89e6d344c6b75c4795c4b44984fac20a numpy-1.25.0rc1-cp39-cp39-macosx_10_9_x86_64.whl
746d67157b23ab8c3f3cbeed1eb3ca6c numpy-1.25.0rc1-cp39-cp39-macosx_11_0_arm64.whl
e5155794ab1680a5e2b62fc8eae403d9 numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
2777450b1791137614fde9505ad9371a numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
10a1729d6126cc9ed75cb64589d916b8 numpy-1.25.0rc1-cp39-cp39-musllinux_1_1_x86_64.whl
e414a13a774f8034da9f8bcfda974653 numpy-1.25.0rc1-cp39-cp39-win32.whl
15ade485b3919f6839af2d30222b2cdd numpy-1.25.0rc1-cp39-cp39-win_amd64.whl
47aaca6df8579400191feac209f87589 numpy-1.25.0rc1-pp39-pypy39_pp73-macosx_10_9_x86_64.whl
8abee7d02cf0b89f15a8a769d31975c0 numpy-1.25.0rc1-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
7aa7729ceb639f1adadd2d1c493a1b9b numpy-1.25.0rc1-pp39-pypy39_pp73-win_amd64.whl
283924a7c0b1050e6b455d86e311c666 numpy-1.25.0rc1.tar.gz
SHA256
bd1de5d7ab75cdf56f2247aace7940dfd0a8fd048e07808358d8fca604f1d102 numpy-1.25.0rc1-cp310-cp310-macosx_10_9_x86_64.whl
a0dab69ef25ccabf6f066a4902e238767cbbe52bc5ff90aa99514f87812ba76a numpy-1.25.0rc1-cp310-cp310-macosx_11_0_arm64.whl
f64b730004e500f836f6405ad5cd36d309b6ac065366a0855860155f23eb2ad5 numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
f8cbdb428d848f03a4f6f534284cf7fb168a6ec0e742357bf65ad268316906ea numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
1365157813810cfda2be9518806bf32f6b5f56e5e501d8299e3b681d53e405e2 numpy-1.25.0rc1-cp310-cp310-musllinux_1_1_x86_64.whl
8aad2f86d2036622af1e1eb9db94e26618f42a571e02583fa72d5b1983782bf8 numpy-1.25.0rc1-cp310-cp310-win32.whl
a4a9f1eaa63b5e35e23e5465ed59746b0a680eb5b5da06f2d432f828d32b26c1 numpy-1.25.0rc1-cp310-cp310-win_amd64.whl
9a18d2c173a44e48e72614748df5624875439af2d352a416b9f3840583ad9efb numpy-1.25.0rc1-cp311-cp311-macosx_10_9_x86_64.whl
1bed69508b3b97dd3fb8c439352881c1bd232a0c8dd1e11d8df4e68046d434cf numpy-1.25.0rc1-cp311-cp311-macosx_11_0_arm64.whl
7cf92c2bfbaf7bd52df1a21e56e8d34cff711594498ecbd02a39df3aaada763b numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
20dd2352806eb229bc79c4fa308431eaf1721c66f7928950ee0381df98a2d269 numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
165b0fb4d5b6349eef7b909be2d61a673bc6e75e0eec43776eea3222385a9d11 numpy-1.25.0rc1-cp311-cp311-musllinux_1_1_x86_64.whl
b1a22ae597ee1d0e2336044854b33965fd92e731efe3c2ab965826e02cca2a8c numpy-1.25.0rc1-cp311-cp311-win32.whl
48e33b46b7db13de75dd0c1c919b8b297b5d7a4dc50b181066977ee17bed7cc3 numpy-1.25.0rc1-cp311-cp311-win_amd64.whl
416da35914d2fecc3afd31127b1eb1a283df33292cfcb453e1c8fb46d52611a1 numpy-1.25.0rc1-cp39-cp39-macosx_10_9_x86_64.whl
f59080829bbfe46660a201fc17315a4e8ec6e4499ee745bab3df61866f63e771 numpy-1.25.0rc1-cp39-cp39-macosx_11_0_arm64.whl
5e7ba92ad63ffded03400d5038af89f7788843794c77ad1a37522fa69762b06f numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
04847257662eef90599a1beca30c757d8e562aa8c7d64e91ea465f299469075d numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
dfe2e3845c3b630f6617f9e8a15c8a1cbaf452c9fa32c71ec0a77d09548cd662 numpy-1.25.0rc1-cp39-cp39-musllinux_1_1_x86_64.whl
7261d100c9bf722057fd5b9cd5b48f2973b17792b41e689eeaf9b55843cd1afd numpy-1.25.0rc1-cp39-cp39-win32.whl
763fca81a8d8beb6bf4b9a9bbf4045b0c134c15ea66c81d26e5b8683b1861293 numpy-1.25.0rc1-cp39-cp39-win_amd64.whl
06bae17a3629416eb5bae3a429655dc075561206b6d3c1ddfa38b51f273bae5c numpy-1.25.0rc1-pp39-pypy39_pp73-macosx_10_9_x86_64.whl
472bdc3ade289d3efa331738b1daa5a529eef0550650f5d5d2eadb936a2f83a5 numpy-1.25.0rc1-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
236c8ff573c02677b873e0934419c8e9873bd2b35aaba885170b7b43cb26d5da numpy-1.25.0rc1-pp39-pypy39_pp73-win_amd64.whl
224e8862a1cd357eede831b270b9e6c51d2cbc2bb5cc2e2b8d0c76d52cbd1edc numpy-1.25.0rc1.tar.gz
```
Links
- PyPI: https://pypi.org/project/numpy
- Changelog: https://pyup.io/changelogs/numpy/
- Homepage: https://www.numpy.org
This PR updates numpy from 1.24.3 to 1.25.0.
Changelog
### 1.25.0 ``` The NumPy 1.25.0 release continues the ongoing work to improve the handling and promotion of dtypes, increase the execution speed, and clarify the documentation. There has also been work to prepare for the future NumPy 2.0.0 release, resulting in a large number of new and expired deprecation. Highlights are: - Support for MUSL, there are now MUSL wheels. - Support the Fujitsu C/C++ compiler. - Object arrays are now supported in einsum - Support for inplace matrix multiplication (`=`). We will be releasing a NumPy 1.26 when Python 12 comes out. That is needed because distutils has been dropped by Python 12 and we will be switching to using meson for future builds. The next mainline release will be NumPy 2.0.0. We plan that the 2.0 series will still support downstream projects built against earlier versions of NumPy. The Python versions supported in this release are 3.9-3.11. Deprecations - `np.core.MachAr` is deprecated. It is private API. In names defined in `np.core` should generally be considered private. ([gh-22638](https://github.com/numpy/numpy/pull/22638)) - `np.finfo(None)` is deprecated. ([gh-23011](https://github.com/numpy/numpy/pull/23011)) - `np.round_` is deprecated. Use `np.round` instead. ([gh-23302](https://github.com/numpy/numpy/pull/23302)) - `np.product` is deprecated. Use `np.prod` instead. ([gh-23314](https://github.com/numpy/numpy/pull/23314)) - `np.cumproduct` is deprecated. Use `np.cumprod` instead. ([gh-23314](https://github.com/numpy/numpy/pull/23314)) - `np.sometrue` is deprecated. Use `np.any` instead. ([gh-23314](https://github.com/numpy/numpy/pull/23314)) - `np.alltrue` is deprecated. Use `np.all` instead. ([gh-23314](https://github.com/numpy/numpy/pull/23314)) - Only ndim-0 arrays are treated as scalars. NumPy used to treat all arrays of size 1 (e.g., `np.array([3.14])`) as scalars. In the future, this will be limited to arrays of ndim 0 (e.g., `np.array(3.14)`). The following expressions will report a deprecation warning: python a = np.array([3.14]) float(a) better: a[0] to get the numpy.float or a.item() b = np.array([[3.14]]) c = numpy.random.rand(10) c[0] = b better: c[0] = b[0, 0] ([gh-10615](https://github.com/numpy/numpy/pull/10615)) - `numpy.find_common_type` is now deprecated and its use should be replaced with either `numpy.result_type` or `numpy.promote_types`. Most users leave the second `scalar_types` argument to `find_common_type` as `[]` in which case `np.result_type` and `np.promote_types` are both faster and more robust. When not using `scalar_types` the main difference is that the replacement intentionally converts non-native byte-order to native byte order. Further, `find_common_type` returns `object` dtype rather than failing promotion. This leads to differences when the inputs are not all numeric. Importantly, this also happens for e.g. timedelta/datetime for which NumPy promotion rules are currently sometimes surprising. When the `scalar_types` argument is not `[]` things are more complicated. In most cases, using `np.result_type` and passing the Python values `0`, `0.0`, or `0j` has the same result as using `int`, `float`, or `complex` in `scalar_types`. When `scalar_types` is constructed, `np.result_type` is the correct replacement and it may be passed scalar values like `np.float32(0.0)`. Passing values other than 0, may lead to value-inspecting behavior (which `np.find_common_type` never used and NEP 50 may change in the future). The main possible change in behavior in this case, is when the array types are signed integers and scalar types are unsigned. If you are unsure about how to replace a use of `scalar_types` or when non-numeric dtypes are likely, please do not hesitate to open a NumPy issue to ask for help. ([gh-22539](https://github.com/numpy/numpy/pull/22539)) Expired deprecations - `np.core.machar` and `np.finfo.machar` have been removed. ([gh-22638](https://github.com/numpy/numpy/pull/22638)) - `+arr` will now raise an error when the dtype is not numeric (and positive is undefined). ([gh-22998](https://github.com/numpy/numpy/pull/22998)) - A sequence must now be passed into the stacking family of functions (`stack`, `vstack`, `hstack`, `dstack` and `column_stack`). ([gh-23019](https://github.com/numpy/numpy/pull/23019)) - `np.clip` now defaults to same-kind casting. Falling back to unsafe casting was deprecated in NumPy 1.17. ([gh-23403](https://github.com/numpy/numpy/pull/23403)) - `np.clip` will now propagate `np.nan` values passed as `min` or `max`. Previously, a scalar NaN was usually ignored. This was deprecated in NumPy 1.17. ([gh-23403](https://github.com/numpy/numpy/pull/23403)) - The `np.dual` submodule has been removed. ([gh-23480](https://github.com/numpy/numpy/pull/23480)) - NumPy now always ignores sequence behavior for an array-like (defining one of the array protocols). (Deprecation started NumPy 1.20) ([gh-23660](https://github.com/numpy/numpy/pull/23660)) - The niche `FutureWarning` when casting to a subarray dtype in `astype` or the array creation functions such as `asarray` is now finalized. The behavior is now always the same as if the subarray dtype was wrapped into a single field (which was the workaround, previously). (FutureWarning since NumPy 1.20) ([gh-23666](https://github.com/numpy/numpy/pull/23666)) - `==` and `!=` warnings have been finalized. The `==` and `!=` operators on arrays now always: - raise errors that occur during comparisons such as when the arrays have incompatible shapes (`np.array([1, 2]) == np.array([1, 2, 3])`). - return an array of all `True` or all `False` when values are fundamentally not comparable (e.g. have different dtypes). An example is `np.array(["a"]) == np.array([1])`. This mimics the Python behavior of returning `False` and `True` when comparing incompatible types like `"a" == 1` and `"a" != 1`. For a long time these gave `DeprecationWarning` or `FutureWarning`. ([gh-22707](https://github.com/numpy/numpy/pull/22707)) - Nose support has been removed. NumPy switched to using pytest in 2018 and nose has been unmaintained for many years. We have kept NumPy\'s nose support to avoid breaking downstream projects who might have been using it and not yet switched to pytest or some other testing framework. With the arrival of Python 3.12, unpatched nose will raise an error. It is time to move on. *Decorators removed*: - raises - slow - setastest - skipif - knownfailif - deprecated - parametrize - \_needs_refcount These are not to be confused with pytest versions with similar names, e.g., pytest.mark.slow, pytest.mark.skipif, pytest.mark.parametrize. *Functions removed*: - Tester - import_nose - run_module_suite ([gh-23041](https://github.com/numpy/numpy/pull/23041)) - The `numpy.testing.utils` shim has been removed. Importing from the `numpy.testing.utils` shim has been deprecated since 2019, the shim has now been removed. All imports should be made directly from `numpy.testing`. ([gh-23060](https://github.com/numpy/numpy/pull/23060)) - The environment variable to disable dispatching has been removed. Support for the `NUMPY_EXPERIMENTAL_ARRAY_FUNCTION` environment variable has been removed. This variable disabled dispatching with `__array_function__`. ([gh-23376](https://github.com/numpy/numpy/pull/23376)) - Support for `y=` as an alias of `out=` has been removed. The `fix`, `isposinf` and `isneginf` functions allowed using `y=` as a (deprecated) alias for `out=`. This is no longer supported. ([gh-23376](https://github.com/numpy/numpy/pull/23376)) Compatibility notes - The `busday_count` method now correctly handles cases where the `begindates` is later in time than the `enddates`. Previously, the `enddates` was included, even though the documentation states it is always excluded. ([gh-23229](https://github.com/numpy/numpy/pull/23229)) - When comparing datetimes and timedelta using `np.equal` or `np.not_equal` numpy previously allowed the comparison with `casting="unsafe"`. This operation now fails. Forcing the output dtype using the `dtype` kwarg can make the operation succeed, but we do not recommend it. ([gh-22707](https://github.com/numpy/numpy/pull/22707)) - When loading data from a file handle using `np.load`, if the handle is at the end of file, as can happen when reading multiple arrays by calling `np.load` repeatedly, numpy previously raised `ValueError` if `allow_pickle=False`, and `OSError` if `allow_pickle=True`. Now it raises `EOFError` instead, in both cases. ([gh-23105](https://github.com/numpy/numpy/pull/23105)) `np.pad` with `mode=wrap` pads with strict multiples of original data Code based on earlier version of `pad` that uses `mode="wrap"` will return different results when the padding size is larger than initial array. `np.pad` with `mode=wrap` now always fills the space with strict multiples of original data even if the padding size is larger than the initial array. ([gh-22575](https://github.com/numpy/numpy/pull/22575)) Cython `long_t` and `ulong_t` removed `long_t` and `ulong_t` were aliases for `longlong_t` and `ulonglong_t` and confusing (a remainder from of Python 2). This change may lead to the errors: 'long_t' is not a type identifier 'ulong_t' is not a type identifier We recommend use of bit-sized types such as `cnp.int64_t` or the use of `cnp.intp_t` which is 32 bits on 32 bit systems and 64 bits on 64 bit systems (this is most compatible with indexing). If C `long` is desired, use plain `long` or `npy_long`. `cnp.int_t` is also `long` (NumPy\'s default integer). However, `long` is 32 bit on 64 bit windows and we may wish to adjust this even in NumPy. (Please do not hesitate to contact NumPy developers if you are curious about this.) ([gh-22637](https://github.com/numpy/numpy/pull/22637)) Changed error message and type for bad `axes` argument to `ufunc` The error message and type when a wrong `axes` value is passed to `ufunc(..., axes=[...])` has changed. The message is now more indicative of the problem, and if the value is mismatched an `AxisError` will be raised. A `TypeError` will still be raised for invalidinput types. ([gh-22675](https://github.com/numpy/numpy/pull/22675)) Array-likes that define `__array_ufunc__` can now override ufuncs if used as `where` If the `where` keyword argument of a `numpy.ufunc`{.interpreted-text role="class"} is a subclass of `numpy.ndarray`{.interpreted-text role="class"} or is a duck type that defines `numpy.class.__array_ufunc__`{.interpreted-text role="func"} it can override the behavior of the ufunc using the same mechanism as the input and output arguments. Note that for this to work properly, the `where.__array_ufunc__` implementation will have to unwrap the `where` argument to pass it into the default implementation of the `ufunc` or, for `numpy.ndarray`{.interpreted-text role="class"} subclasses before using `super().__array_ufunc__`. ([gh-23240](https://github.com/numpy/numpy/pull/23240)) By default, the exported NumPy C API is now compatible with NumPy 1.19 Starting with NumPy 1.25 when including NumPy headers, NumPy now defaults to exposing a backwards compatible API. This means that by default binaries such as wheels build against NumPy 1.25 will also work with NumPy 1.16 because it has the same API version as NumPy 1.19 which is the oldest NumPy version compatible with Python 3.9. You can customize this behavior using: define NPY_TARGET_VERSION NPY_1_22_API_VERSION or the equivalent `-D` option to the compiler. For more details please see `for-downstream-package-authors`{.interpreted-text role="ref"}. A change should only be required in rare cases when a package relies on newly added C-API. ([gh-23528](https://github.com/numpy/numpy/pull/23528)) New Features `np.einsum` now accepts arrays with `object` dtype The code path will call python operators on object dtype arrays, much like `np.dot` and `np.matmul`. ([gh-18053](https://github.com/numpy/numpy/pull/18053)) Add support for inplace matrix multiplication It is now possible to perform inplace matrix multiplication via the `=` operator. python >>> import numpy as np >>> a = np.arange(6).reshape(3, 2) >>> print(a) [[0 1] [2 3] [4 5]] >>> b = np.ones((2, 2), dtype=int) >>> a = b >>> print(a) [[1 1] [5 5] [9 9]] ([gh-21120](https://github.com/numpy/numpy/pull/21120)) Added `NPY_ENABLE_CPU_FEATURES` environment variable Users may now choose to enable only a subset of the built CPU features at runtime by specifying the `NPY_ENABLE_CPU_FEATURES` environment variable. Note that these specified features must be outside the baseline, since those are always assumed. Errors will be raised if attempting to enable a feature that is either not supported by your CPU, or that NumPy was not built with. ([gh-22137](https://github.com/numpy/numpy/pull/22137)) NumPy now has an `np.exceptions` namespace NumPy now has a dedicated namespace making most exceptions and warnings available. All of these remain available in the main namespace, although some may be moved slowly in the future. The main reason for this is to increase discoverability and add future exceptions. ([gh-22644](https://github.com/numpy/numpy/pull/22644)) `np.linalg` functions return NamedTuples `np.linalg` functions that return tuples now return namedtuples. These functions are `eig()`, `eigh()`, `qr()`, `slogdet()`, and `svd()`. The return type is unchanged in instances where these functions return non-tuples with certain keyword arguments (like `svd(compute_uv=False)`). ([gh-22786](https://github.com/numpy/numpy/pull/22786)) String functions in `np.char` are compatible with NEP 42 custom dtypes Custom dtypes that represent unicode strings or byte strings can now be passed to the string functions in `np.char`. ([gh-22863](https://github.com/numpy/numpy/pull/22863)) String dtype instances can be created from the string abstract dtype classes It is now possible to create a string dtype instance with a size without using the string name of the dtype. For example, `type(np.dtype('U'))(8)` will create a dtype that is equivalent to `np.dtype('U8')`. This feature is most useful when writing generic code dealing with string dtype classes. ([gh-22963](https://github.com/numpy/numpy/pull/22963)) Fujitsu C/C++ compiler is now supported Support for Fujitsu compiler has been added. To build with Fujitsu compiler, run: > python setup.py build -c fujitsu SSL2 is now supported Support for SSL2 has been added. SSL2 is a library that provides OpenBLAS compatible GEMM functions. To enable SSL2, it need to edit site.cfg and build with Fujitsu compiler. See site.cfg.example. ([gh-22982](https://github.com/numpy/numpy/pull/22982)) Improvements `NDArrayOperatorsMixin` specifies that it has no `__slots__` The `NDArrayOperatorsMixin` class now specifies that it contains no `__slots__`, ensuring that subclasses can now make use of this feature in Python. ([gh-23113](https://github.com/numpy/numpy/pull/23113)) Fix power of complex zero `np.power` now returns a different result for `0^{non-zero}` for complex numbers. Note that the value is only defined when the real part of the exponent is larger than zero. Previously, NaN was returned unless the imaginary part was strictly zero. The return value is either `0+0j` or `0-0j`. ([gh-18535](https://github.com/numpy/numpy/pull/18535)) New `DTypePromotionError` NumPy now has a new `DTypePromotionError` which is used when two dtypes cannot be promoted to a common one, for example: np.result_type("M8[s]", np.complex128) raises this new exception. ([gh-22707](https://github.com/numpy/numpy/pull/22707)) `np.show_config` uses information from Meson Build and system information now contains information from Meson. `np.show_config` now has a new optional parameter `mode` to help customize the output. ([gh-22769](https://github.com/numpy/numpy/pull/22769)) Fix `np.ma.diff` not preserving the mask when called with arguments prepend/append. Calling `np.ma.diff` with arguments prepend and/or append now returns a `MaskedArray` with the input mask preserved. Previously, a `MaskedArray` without the mask was returned. ([gh-22776](https://github.com/numpy/numpy/pull/22776)) Corrected error handling for NumPy C-API in Cython Many NumPy C functions defined for use in Cython were lacking the correct error indicator like `except -1` or `except *`. These have now been added. ([gh-22997](https://github.com/numpy/numpy/pull/22997)) Ability to directly spawn random number generators `numpy.random.Generator.spawn` now allows to directly spawn new independent child generators via the `numpy.random.SeedSequence.spawn` mechanism. `numpy.random.BitGenerator.spawn` does the same for the underlying bit generator. Additionally, `numpy.random.BitGenerator.seed_seq` now gives direct access to the seed sequence used for initializing the bit generator. This allows for example: seed = 0x2e09b90939db40c400f8f22dae617151 rng = np.random.default_rng(seed) child_rng1, child_rng2 = rng.spawn(2) safely use rng, child_rng1, and child_rng2 Previously, this was hard to do without passing the `SeedSequence` explicitly. Please see `numpy.random.SeedSequence` for more information. ([gh-23195](https://github.com/numpy/numpy/pull/23195)) `numpy.logspace` now supports a non-scalar `base` argument The `base` argument of `numpy.logspace` can now be array-like if it is broadcastable against the `start` and `stop` arguments. ([gh-23275](https://github.com/numpy/numpy/pull/23275)) `np.ma.dot()` now supports for non-2d arrays Previously `np.ma.dot()` only worked if `a` and `b` were both 2d. Now it works for non-2d arrays as well as `np.dot()`. ([gh-23322](https://github.com/numpy/numpy/pull/23322)) Explicitly show keys of .npz file in repr `NpzFile` shows keys of loaded .npz file when printed. python >>> npzfile = np.load('arr.npz') >>> npzfile NpzFile 'arr.npz' with keys arr_0, arr_1, arr_2, arr_3, arr_4... ([gh-23357](https://github.com/numpy/numpy/pull/23357)) NumPy now exposes DType classes in `np.dtypes` The new `numpy.dtypes` module now exposes DType classes and will contain future dtype related functionality. Most users should have no need to use these classes directly. ([gh-23358](https://github.com/numpy/numpy/pull/23358)) Drop dtype metadata before saving in .npy or .npz files Currently, a `*.npy` file containing a table with a dtype with metadata cannot be read back. Now, `np.save` and `np.savez` drop metadata before saving. ([gh-23371](https://github.com/numpy/numpy/pull/23371)) `numpy.lib.recfunctions.structured_to_unstructured` returns views in more cases `structured_to_unstructured` now returns a view, if the stride between the fields is constant. Prior, padding between the fields or a reversed field would lead to a copy. This change only applies to `ndarray`, `memmap` and `recarray`. For all other array subclasses, the behavior remains unchanged. ([gh-23652](https://github.com/numpy/numpy/pull/23652)) Signed and unsigned integers always compare correctly When `uint64` and `int64` are mixed in NumPy, NumPy typically promotes both to `float64`. This behavior may be argued about but is confusing for comparisons `==`, `<=`, since the results returned can be incorrect but the conversion is hidden since the result is a boolean. NumPy will now return the correct results for these by avoiding the cast to float. ([gh-23713](https://github.com/numpy/numpy/pull/23713)) Performance improvements and changes Faster `np.sort` on AVX-512 enabled processors Quicksort for 16-bit and 64-bit dtypes gain up to 15x and 9x speed up on processors that support AVX-512 instruction set. Thanks to [Intel corporation](https://open.intel.com/) for sponsoring this work. ([gh-22315](https://github.com/numpy/numpy/pull/22315)) `__array_function__` machinery is now much faster The overhead of the majority of functions in NumPy is now smaller especially when keyword arguments are used. This change significantly speeds up many simple function calls. ([gh-23020](https://github.com/numpy/numpy/pull/23020)) `ufunc.at` can be much faster Generic `ufunc.at` can be up to 9x faster. The conditions for this speedup: - operands are aligned - no casting If ufuncs with appropriate indexed loops on 1d arguments with the above conditions, `ufunc.at` can be up to 60x faster (an additional 7x speedup). Appropriate indexed loops have been added to `add`, `subtract`, `multiply`, `floor_divide`, `maximum`, `minimum`, `fmax`, and `fmin`. The internal logic is similar to the logic used for regular ufuncs, which also have fast paths. Thanks to the [D. E. Shaw group](https://deshaw.com/) for sponsoring this work. ([gh-23136](https://github.com/numpy/numpy/pull/23136)) Faster membership test on `NpzFile` Membership test on `NpzFile` will no longer decompress the archive if it is successful. ([gh-23661](https://github.com/numpy/numpy/pull/23661)) Changes `np.r_[]` and `np.c_[]` with certain scalar values In rare cases, using mainly `np.r_` with scalars can lead to different results. The main potential changes are highlighted by the following: >>> np.r_[np.arange(5, dtype=np.uint8), -1].dtype int16 rather than the default integer (int64 or int32) >>> np.r_[np.arange(5, dtype=np.int8), 255] array([ 0, 1, 2, 3, 4, 255], dtype=int16) Where the second example returned: array([ 0, 1, 2, 3, 4, -1], dtype=int8) The first one is due to a signed integer scalar with an unsigned integer array, while the second is due to `255` not fitting into `int8` and NumPy currently inspecting values to make this work. (Note that the second example is expected to change in the future due to `NEP 50 <NEP50>`{.interpreted-text role="ref"}; it will then raise an error.) ([gh-22539](https://github.com/numpy/numpy/pull/22539)) Most NumPy functions are wrapped into a C-callable To speed up the `__array_function__` dispatching, most NumPy functions are now wrapped into C-callables and are not proper Python functions or C methods. They still look and feel the same as before (like a Python function), and this should only improve performance and user experience (cleaner tracebacks). However, please inform the NumPy developers if this change confuses your program for some reason. ([gh-23020](https://github.com/numpy/numpy/pull/23020)) C++ standard library usage NumPy builds now depend on the C++ standard library, because the `numpy.core._multiarray_umath` extension is linked with the C++ linker. ([gh-23601](https://github.com/numpy/numpy/pull/23601)) Checksums MD5 fbbc825509a7c07b510670d28ef8bbfa numpy-1.25.0rc1-cp310-cp310-macosx_10_9_x86_64.whl 4e180a777fb108729c5899f5d0dd809c numpy-1.25.0rc1-cp310-cp310-macosx_11_0_arm64.whl d21d3e363c6e3ecef94a3cc9a014bd40 numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 3d0d215ea9f1c0bcf2544133cfae4e60 numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl fc7b40a9a38825e7065a3f68403870f1 numpy-1.25.0rc1-cp310-cp310-musllinux_1_1_x86_64.whl b8277ceaf6893fa15cbfc550c23d0b87 numpy-1.25.0rc1-cp310-cp310-win32.whl 06018e514aea30f8bf533cdb05536e1f numpy-1.25.0rc1-cp310-cp310-win_amd64.whl c74a294da0fbb44f3cf625527448ced7 numpy-1.25.0rc1-cp311-cp311-macosx_10_9_x86_64.whl 342eaeed6ba93fe58fcf0c70ed4df191 numpy-1.25.0rc1-cp311-cp311-macosx_11_0_arm64.whl 43c70b2d9fedd62053b9c5aac254eed2 numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl eedfedfd3b08cce4969a5688bc11217d numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl a97d41371f7a9b71be54091868c907ce numpy-1.25.0rc1-cp311-cp311-musllinux_1_1_x86_64.whl 9f23c161c940c2d5c88f6f2a96947edd numpy-1.25.0rc1-cp311-cp311-win32.whl 316c96a7a991af57a3956be3f070856b numpy-1.25.0rc1-cp311-cp311-win_amd64.whl 89e6d344c6b75c4795c4b44984fac20a numpy-1.25.0rc1-cp39-cp39-macosx_10_9_x86_64.whl 746d67157b23ab8c3f3cbeed1eb3ca6c numpy-1.25.0rc1-cp39-cp39-macosx_11_0_arm64.whl e5155794ab1680a5e2b62fc8eae403d9 numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 2777450b1791137614fde9505ad9371a numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 10a1729d6126cc9ed75cb64589d916b8 numpy-1.25.0rc1-cp39-cp39-musllinux_1_1_x86_64.whl e414a13a774f8034da9f8bcfda974653 numpy-1.25.0rc1-cp39-cp39-win32.whl 15ade485b3919f6839af2d30222b2cdd numpy-1.25.0rc1-cp39-cp39-win_amd64.whl 47aaca6df8579400191feac209f87589 numpy-1.25.0rc1-pp39-pypy39_pp73-macosx_10_9_x86_64.whl 8abee7d02cf0b89f15a8a769d31975c0 numpy-1.25.0rc1-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 7aa7729ceb639f1adadd2d1c493a1b9b numpy-1.25.0rc1-pp39-pypy39_pp73-win_amd64.whl 283924a7c0b1050e6b455d86e311c666 numpy-1.25.0rc1.tar.gz SHA256 bd1de5d7ab75cdf56f2247aace7940dfd0a8fd048e07808358d8fca604f1d102 numpy-1.25.0rc1-cp310-cp310-macosx_10_9_x86_64.whl a0dab69ef25ccabf6f066a4902e238767cbbe52bc5ff90aa99514f87812ba76a numpy-1.25.0rc1-cp310-cp310-macosx_11_0_arm64.whl f64b730004e500f836f6405ad5cd36d309b6ac065366a0855860155f23eb2ad5 numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl f8cbdb428d848f03a4f6f534284cf7fb168a6ec0e742357bf65ad268316906ea numpy-1.25.0rc1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 1365157813810cfda2be9518806bf32f6b5f56e5e501d8299e3b681d53e405e2 numpy-1.25.0rc1-cp310-cp310-musllinux_1_1_x86_64.whl 8aad2f86d2036622af1e1eb9db94e26618f42a571e02583fa72d5b1983782bf8 numpy-1.25.0rc1-cp310-cp310-win32.whl a4a9f1eaa63b5e35e23e5465ed59746b0a680eb5b5da06f2d432f828d32b26c1 numpy-1.25.0rc1-cp310-cp310-win_amd64.whl 9a18d2c173a44e48e72614748df5624875439af2d352a416b9f3840583ad9efb numpy-1.25.0rc1-cp311-cp311-macosx_10_9_x86_64.whl 1bed69508b3b97dd3fb8c439352881c1bd232a0c8dd1e11d8df4e68046d434cf numpy-1.25.0rc1-cp311-cp311-macosx_11_0_arm64.whl 7cf92c2bfbaf7bd52df1a21e56e8d34cff711594498ecbd02a39df3aaada763b numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 20dd2352806eb229bc79c4fa308431eaf1721c66f7928950ee0381df98a2d269 numpy-1.25.0rc1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 165b0fb4d5b6349eef7b909be2d61a673bc6e75e0eec43776eea3222385a9d11 numpy-1.25.0rc1-cp311-cp311-musllinux_1_1_x86_64.whl b1a22ae597ee1d0e2336044854b33965fd92e731efe3c2ab965826e02cca2a8c numpy-1.25.0rc1-cp311-cp311-win32.whl 48e33b46b7db13de75dd0c1c919b8b297b5d7a4dc50b181066977ee17bed7cc3 numpy-1.25.0rc1-cp311-cp311-win_amd64.whl 416da35914d2fecc3afd31127b1eb1a283df33292cfcb453e1c8fb46d52611a1 numpy-1.25.0rc1-cp39-cp39-macosx_10_9_x86_64.whl f59080829bbfe46660a201fc17315a4e8ec6e4499ee745bab3df61866f63e771 numpy-1.25.0rc1-cp39-cp39-macosx_11_0_arm64.whl 5e7ba92ad63ffded03400d5038af89f7788843794c77ad1a37522fa69762b06f numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 04847257662eef90599a1beca30c757d8e562aa8c7d64e91ea465f299469075d numpy-1.25.0rc1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl dfe2e3845c3b630f6617f9e8a15c8a1cbaf452c9fa32c71ec0a77d09548cd662 numpy-1.25.0rc1-cp39-cp39-musllinux_1_1_x86_64.whl 7261d100c9bf722057fd5b9cd5b48f2973b17792b41e689eeaf9b55843cd1afd numpy-1.25.0rc1-cp39-cp39-win32.whl 763fca81a8d8beb6bf4b9a9bbf4045b0c134c15ea66c81d26e5b8683b1861293 numpy-1.25.0rc1-cp39-cp39-win_amd64.whl 06bae17a3629416eb5bae3a429655dc075561206b6d3c1ddfa38b51f273bae5c numpy-1.25.0rc1-pp39-pypy39_pp73-macosx_10_9_x86_64.whl 472bdc3ade289d3efa331738b1daa5a529eef0550650f5d5d2eadb936a2f83a5 numpy-1.25.0rc1-pp39-pypy39_pp73-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 236c8ff573c02677b873e0934419c8e9873bd2b35aaba885170b7b43cb26d5da numpy-1.25.0rc1-pp39-pypy39_pp73-win_amd64.whl 224e8862a1cd357eede831b270b9e6c51d2cbc2bb5cc2e2b8d0c76d52cbd1edc numpy-1.25.0rc1.tar.gz ```Links
- PyPI: https://pypi.org/project/numpy - Changelog: https://pyup.io/changelogs/numpy/ - Homepage: https://www.numpy.org