diff options
| author | Sebastian Berg <sebastian@sipsolutions.net> | 2020-06-25 12:58:28 -0500 |
|---|---|---|
| committer | Sebastian Berg <sebastian@sipsolutions.net> | 2020-07-08 18:13:06 -0500 |
| commit | 4fe0ad2eb3342531723f0342fb14a96d4497decb (patch) | |
| tree | bdaa466cdf8c1fabccb5ecdf3e70c46f991599f1 /doc/release | |
| parent | e3f091e3e9e0055f37527cb10b2ed5832153b23b (diff) | |
| download | numpy-4fe0ad2eb3342531723f0342fb14a96d4497decb.tar.gz | |
MAINT: Put a hack in place to allow datetime64 -> string assignment when string is too short
this retains (and slightly expands) the old behaviour. It is inconsistent
and I think we should fix that inconsistency one way or the other
(I honestly do not care *which* way).
Diffstat (limited to 'doc/release')
| -rw-r--r-- | doc/release/upcoming_changes/16200.compatibility.rst | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/doc/release/upcoming_changes/16200.compatibility.rst b/doc/release/upcoming_changes/16200.compatibility.rst index c95165af7..a067079cc 100644 --- a/doc/release/upcoming_changes/16200.compatibility.rst +++ b/doc/release/upcoming_changes/16200.compatibility.rst @@ -16,6 +16,12 @@ will succeed at this time (this may change) and return an undefined result 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. +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")`` +succeeds now, when it failed before. In the long term this may be +deprecate this or the unsafe cast may be allowed generally to make assignment +of arrays and scalars behave consistently. Array coercion changes when Strings and other types are mixed |