-
-
Notifications
You must be signed in to change notification settings - Fork 18.6k
REF: de-duplicate ndarray[datetimelike] wrapping #38129
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
Changes from 2 commits
3454697
57d7aa7
545ca5a
e0adba9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -402,6 +402,24 @@ def extract_array(obj: object, extract_numpy: bool = False) -> Union[Any, ArrayL | |
return obj | ||
|
||
|
||
def wrap_if_datetimelike(arr): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can you type the arg (and return dtype) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not really, its unrestricted There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. aren't these always TDI/DTI on the return type? (sure input is just ArrayLike) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no, we call it on arbitrary inputs in ops.array_ops There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok then i am misunderstanding how this is used and its definetly maybe_wrap_if_datetimelike, its either ensure or maybe, really shouldn't be any other choices. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok will update There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. renamed + greenish |
||
""" | ||
Wrap datetime64 and timedelta64 ndarrays in DatetimeArray/TimedeltaArray. | ||
""" | ||
if isinstance(arr, np.ndarray): | ||
if arr.dtype.kind == "M": | ||
from pandas.core.arrays import DatetimeArray | ||
|
||
return DatetimeArray._from_sequence(arr) | ||
|
||
elif arr.dtype.kind == "m": | ||
from pandas.core.arrays import TimedeltaArray | ||
|
||
return TimedeltaArray._from_sequence(arr) | ||
|
||
return arr | ||
|
||
|
||
def sanitize_array( | ||
data, | ||
index: Optional[Index], | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree with joris that
maybe_*
is pretty much a convention and would go with that nomenclature.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe_do_x usually means "try to do x and fallback on failure". i think wrap_if_datetimelike is more precise on this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok how about
ensure_datetimelike_index then