diff options
author | Sebastian Berg <sebastian@sipsolutions.net> | 2020-09-30 13:55:54 -0500 |
---|---|---|
committer | Sebastian Berg <sebastian@sipsolutions.net> | 2020-10-01 10:57:06 -0500 |
commit | a2e76ff3dc1e19203b2529d939f489ca04ab98a0 (patch) | |
tree | eb1439daeb26ce151a20484fac6b83c291d3a840 /doc/release | |
parent | 60945085cfd1abf4e04db461040bc675f1d325c7 (diff) | |
download | numpy-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.rst | 22 |
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")`` |