-
-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AttributeError on datetime.timedelta assignment after reindex #8209
Comments
FIxed in the refactoring of timedeltas in general (#8184), here's the fix: jreback@ea09610 in the interim you can simply do:
The issue was its not coercing the |
@jreback I was just looking at this too - is |
ie., something like this diff: diff --git a/pandas/core/internals.py b/pandas/core/internals.py
index 6672546..cfbdcd7 100644
--- a/pandas/core/internals.py
+++ b/pandas/core/internals.py
@@ -1224,6 +1224,16 @@ class TimeDeltaBlock(IntBlock):
_can_hold_na = True
is_numeric = False
+ def _can_hold_element(self, value):
+ if is_list_like(value):
+ value = np.array(value)
+ typ = value.dtype.type
+ return (issubclass(typ, (np.integer, np.timedelta64, np.float_)) and not
+ issubclass(typ, np.datetime64))
+ return (isinstance(value, (np.timedelta64, timedelta, np.float_,
+ float)) or
+ com.is_integer(value) or _is_null_datelike_scalar(value))
+
@property
def fill_value(self):
return tslib.iNaT |
No, it can ONLY hold integers! (and its a sub-class of regardless, this Bug will is fixed already in #8184 |
@jreback no no - I was just wrong about the level of the bug. Trying to dip my foot back into internals again (just a little bit) |
@jtratner hah, no prob. as I said, this |
Thanks for the reply, +1 for the refactor PR! BTW, a side question: is there a way to force pandas to store datetime.timedelta as object dtypes? The intuitive solution does not work: In [57]: s = pd.Series([dt.timedelta(days=1)], dtype=object)
In [58]: s
Out[58]:
0 1 days
dtype: timedelta64[ns] Neither via numpy arrays: In [91]: tdarr = np.array([dt.timedelta(days=1)])
In [92]: tdarr
Out[92]: array([datetime.timedelta(1)], dtype=object)
In [93]: s = pd.Series(tdarr)
In [94]: s
Out[94]:
0 1 days
dtype: timedelta64[ns] I understand that this will be a non-issue when the PR is merged, but in the meantime I have to fix my app which expects datetime.timedeltas. I wouldn't mind to switch to np.timedelta64, but it's undeniable that working with np.timestamp64 is far from being convenient (e.g. no "days" property, "total_seconds()" etc.). And (AFAIK) there is no easy, standard way to bring a np.timestamp64 back to datetime.timedelta, which only adds to the PITA... Thanks again. |
@flaviovs that used to work :) There's actually a really easy way to convert timedelta64 to python timedelta: In [25]: import numpy as np
In [26]: import datetime as dt
In [27]: arr = np.array([np.timedelta64(dt.timedelta(232)), np.timedelta64(dt.timedelta(13))])
In [28]: arr.astype(object)
Out[28]: array([datetime.timedelta(232), datetime.timedelta(13)], dtype=object) (and that works on individual timedelta objects too) |
@flaviovs you can use @jtratner soln in the interim, or if you are up for trying out the new PR (will be merged soon), then this will work (which is very similar to how Timestamp/datetimes work):
|
@jtratner, your solution uses numpy arrays. My conceptual question is how to have a pandas.Series containint datetime.timedelta's stored as object dtypes... p.s.: I'm relatively new to GitHub and not used to issues workflow, thus I'm not closing this issue. Feel free to close it, as I'm finished. Let me know if you prefer I do the close. Thx |
@flaviovs this will be close when I merge in the PR. thanks. |
In the code below, I expected that the assignment didn't fail, since everything seems "right" . However, AttributeError is being raised.
A bug? Am I doing something wrong?
Tried with 0.14.1 and latest on GH (v0.15pre) , to no avail.
I'm so sorry I'm not able to provide a patch right now (still wrapping my head around pandas internals -- any directions about how to fix this is issue will be appreciated, though).
Versions:
The text was updated successfully, but these errors were encountered: