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 3.12 comes out. That is
needed because distutils has been dropped by Python 3.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))
Compiling against the NumPy C API is now backwards compatible by default
NumPy now defaults to exposing a backwards compatible subset of the
C-API. This makes the use of `oldest-supported-numpy` unnecessary.
Libraries can override the default minimal version to be compatible with
using:
define NPY_TARGET_VERSION NPY_1_22_API_VERSION
before including NumPy or by passing the equivalent `-D` option to the
compiler. The NumPy 1.25 default is `NPY_1_19_API_VERSION`. Because the