From f301fb10559584e6e04e39a38476c82e4b073579 Mon Sep 17 00:00:00 2001 From: Sebastian Berg Date: Sun, 12 Jun 2022 13:50:24 -0700 Subject: [PATCH] DOC: Shorten release note about `arr.fill()` change Co-authored-by: Matti Picus --- .../upcoming_changes/20924.compatibility.rst | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/doc/release/upcoming_changes/20924.compatibility.rst b/doc/release/upcoming_changes/20924.compatibility.rst index 68b7e48927b4..0446b714fe94 100644 --- a/doc/release/upcoming_changes/20924.compatibility.rst +++ b/doc/release/upcoming_changes/20924.compatibility.rst @@ -8,16 +8,4 @@ now due to the fact that the logic is aligned with item assignment:: # is now identical to: arr[0] = scalar -When previously, effectively ``arr.fill(np.asarray(scalar))`` was used -in many cases. -The typical possible change is that errors will be given for example for -``np.array([0]).fill(1e300)`` or ``np.array([0]).fill(np.nan)``. -Previously, ``arr.fill()`` would unpack 0-D object arrays if the input -array was also of object dtype, the 0-D array will now be stored as is:: - - >>> arr = np.array([0], dtype=object) - >>> arr.fill(np.array(None, dtype=object)) - >>> arr - array([array(None, dtype=object)], dtype=object) - -Rather than ``array([None], dtype=object)``. +Previously casting may have produced slightly different answers when using values that could not be represented in the target `dtype` or when using `object`s.