DEPR: undo deprecation of astype(int64) for datetimelike values #45449
Conversation
jorisvandenbossche
added
API - Consistency
| @@ -430,14 +430,6 @@ def astype(self, dtype, copy: bool = True): | |||
| elif is_integer_dtype(dtype): | |||
| # we deliberately ignore int32 vs. int64 here. | |||
| # See https://github.com/pandas-dev/pandas/issues/24381 for more. | |||
There was a problem hiding this comment.
im OK with un-deprecating for the time being for i8. any objection to maintaining the deprecation for integer dtypes other than i8?
There was a problem hiding this comment.
Other integer dtypes should IMO certainly use astype instead of view? (eg view(int32) doesn't make much sense since the original dtype is 64-bit)
There was a problem hiding this comment.
I'm saying if the user does arr.astype(np.uint32) it doesn't make sense to give them arr.view(np.int64). i.e. we should keep the deprecation for dtypes other than np.int64.
There was a problem hiding this comment.
And what I say is that it makes even less sense to ask them to do .view(np.int32) instead of giving them .view(np.int64) ;) (which will actually raise).
I understand that we are ignoring the bit-width here, and that is something we should fix. But I think that is unrelated to the "use view instead" deprecation (I also don't know if that is something we should deprecate first, or simply change).
There was a problem hiding this comment.
Actually, we might be ignoring bit-width here, but that gets catched elsewhere. Because astyping to something else as int64/uint64 actually already raises an error at the moment (see also the table in #45034 (comment))
At least, that gets catched on the Series level. As you mentioned in that issue, the cast is allowed (bit width is ignored) at the array level.
There was a problem hiding this comment.
And what I say is that it makes even less sense to ask them to do .view(np.int32) instead of giving them .view(np.int64) ;) (which will actually raise).
huh? If a user does dta.astype(np.uint32) im not advocating returning dta.view(np.int32), im advocating raising (or at least deprecating now and raising in the future).
Actually, we might be ignoring bit-width here, but that gets catched elsewhere. Because astyping to something else as int64/uint64 actually already raises an error at the moment (see also the table in #45034 (comment))
Yah we should try to handle these all symmetrically.
There was a problem hiding this comment.
huh? If a user does dta.astype(np.uint32) im not advocating returning dta.view(np.int32), im advocating raising (or at least deprecating now and raising in the future).
I know that you are not advocating for that, but is is what the current deprecation warning implies the user to do (as is says to use view instead of astype).
You asked to "maintain the deprecation" for those cases, and what I am trying to say is that we should indeed fix those cases (in some way, with a different deprecation or breaking change (depending on the future behaviour), to be discussed), but IMO not by maintaining the current deprecation.
|
ok so going to back to using .astype here rather than .view, ok with that. |
|
ok this is fine. @jorisvandenbossche @jbrockmendel ok here? |
|
sure, can merge this for 1.4 and can hammer out better solution for 1.5 |
|
thanks @jorisvandenbossche |
|
@meeseeksdev backport 1.4.x |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@jorisvandenbossche if you'd push a manual backport here |
…imelike values (#45518)
Closes #45034