Repository navigation
BUG/API: dt64.astype(object), dt64.item() - #23205
jbrockmendel wants to merge 4 commits into
Conversation
|
Thanks for picking this up!
Numpy doesn't do semver, so as long as there's a way to show a deprecation warning for 2-3 releases, it doesn't necessarily need to wait for the mythical 2.0 |
Happy to do it. I'm looking forward to ripping out a bunch of pandas code that works around the current behavior. I am stuck on the existing segfaults (see comments in the tests), could use a hand if you're up for it. |
gentype having int/float that goes to array, and array having one that goes to the scalar doesn't make sense. So just solve the issue by making the gentype version always an error. (Could put it on the datetime, but it seems not useful. Simply not implementing it isn't great, because `int()` seems to try to interpret things as a buffer somehow.)
|
Rebased, and fixed the segfault (that could be split out, it should be a safe maintenance commit). This means assigning timedelta into integer arrays fails, that could be recovered (there are two ways even, but not a priority). The main issue now is still the infinite recursion, which is the same as the segfault really. Scalar python operators fall back to the array path, but the object array ufuncs use the Python operators. That is a terrible thing! In general, we should just refuse and return I think I would be up for trying to kill that in NumPy 2.0. Dropping down to the python type may be fine for integers and In any case, the fix is to make sure that doesn't happen for times. |
| else { | ||
| return PyDelta_FromDSU(days, seconds, useconds); | ||
| } | ||
| } |
There was a problem hiding this comment.
Maybe one should keep this? Probably not as .item() but for some kind of way to convert to Python datetime?
|
Based on a discussion at the triage meeting, we decided to close inactive draft PRs that are more than 1 year old. Feel free to open a new PR to continue working on this. |
|
Maybe give some time to respond before closing? Opening a new PR loses all the accumulated context of an existing PR. |
|
We can reopen the PR if that would be a better option than starting a new one. At the triage meeting today we decided to close draft PRs that were more than a year old, so help drop the number of open PRs. |
Has some segfaults that need to be worked out.
Constitutes an API change that may need to wait for 2.0.
closes #19782
closes #18363
closes #12550
closes #7945
closes #7619
(i think)