summaryrefslogtreecommitdiff
path: root/doc/release
diff options
context:
space:
mode:
authorSebastian Berg <sebastian@sipsolutions.net>2020-09-30 13:55:54 -0500
committerSebastian Berg <sebastian@sipsolutions.net>2020-10-01 10:57:06 -0500
commita2e76ff3dc1e19203b2529d939f489ca04ab98a0 (patch)
treeeb1439daeb26ce151a20484fac6b83c291d3a840 /doc/release
parent60945085cfd1abf4e04db461040bc675f1d325c7 (diff)
downloadnumpy-a2e76ff3dc1e19203b2529d939f489ca04ab98a0.tar.gz
API: Special case how numpy scalars are coerced to signed integer
This removes one of the larger changes to array-coercion, which meant that NumPy scalars were always coerced like a 0-D array would be (i.e. using normal casting). When the assignment is explicitly an integer, now `scalar.__int__()` will be used instead (as was the case previously). Since previously this was handled differently, a *single* scalar is still converted using casting: np.array(np.float64(np.nan), dtype=np.int64) succeeds, but any other thing fails, such as: np.array([np.float64(np.nan)], dtype=np.int64) arr1d_int64[()] = np.float64(np.nan) np.array(np.array(np.nan), dtype=np.int64) This does not affect Python scalars, that always raise, because they always are converted using `scalar.__int__()`. Unsigned integers always supported casting from their signed equivalent, so the difference is much less visible for them and this chooses to always use the casting behaviour. The main reason for this change is to help pands: https://github.com/pandas-dev/pandas/issues/35481
Diffstat (limited to 'doc/release')
-rw-r--r--doc/release/upcoming_changes/16200.compatibility.rst22
1 files changed, 17 insertions, 5 deletions
diff --git a/doc/release/upcoming_changes/16200.compatibility.rst b/doc/release/upcoming_changes/16200.compatibility.rst
index d0fd51265..2bbdd883e 100644
--- a/doc/release/upcoming_changes/16200.compatibility.rst
+++ b/doc/release/upcoming_changes/16200.compatibility.rst
@@ -8,14 +8,26 @@ error::
np.array([np.float64(np.nan)], dtype=np.int64)
-will succeed at this time (this may change) and return an undefined result
-(usually the smallest possible integer). This also affects assignments::
+will succeed and return an undefined result (usually the smallest possible
+integer). This also affects assignments::
arr[0] = np.float64(np.nan)
-Note, this already happened for ``np.array(np.float64(np.nan), dtype=np.int64)``
-and that the behaviour is unchanged for ``np.nan`` itself which is a Python
-float.
+At this time, NumPy retains the behaviour for::
+
+ np.array(np.float64(np.nan), dtype=np.int64)
+
+The above changes do not affect Python scalars:
+
+ np.array([float("NaN")], dtype=np.int64)
+
+remains unaffected (``np.nan`` is a Python ``float``, not a NumPy one).
+Unlike signed integers, unsigned integers do not retain this special case,
+since they always behaved more like casting.
+The following code stops raising an error::
+
+ np.array([np.float64(np.nan)], dtype=np.uint64)
+
To avoid backward compatibility issues, at this time assignment from
``datetime64`` scalar to strings of too short length remains supported.
This means that ``np.asarray(np.datetime64("2020-10-10"), dtype="S5")``