Skip to content

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

Merged
merged 4 commits into from
Nov 29, 2020

Conversation

jbrockmendel
Copy link
Member

No description provided.

Copy link
Member

@jorisvandenbossche jorisvandenbossche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I find the "maybe" in the name useful here, as in my head, our "maybe" function maybe do something with the input, but otherwise return it not modified (I don't know if we consistently follow that logic though, for all our maybe_ functions). While "wrap_datetimelike" sounds as it always wraps a datetimelike (maybe_wrap_datetimelike?)

@jbrockmendel
Copy link
Member Author

wrap_if_datetimelike?

@@ -402,6 +402,24 @@ def extract_array(obj: object, extract_numpy: bool = False) -> Union[Any, ArrayL
return obj


def wrap_if_datetimelike(arr):
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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

@@ -402,6 +402,24 @@ def extract_array(obj: object, extract_numpy: bool = False) -> Union[Any, ArrayL
return obj


def wrap_if_datetimelike(arr):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you type the arg (and return dtype)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not really, its unrestricted

Copy link
Contributor

Choose a reason for hiding this comment

The 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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, we call it on arbitrary inputs in ops.array_ops

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok will update

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renamed + greenish

@jreback jreback added Refactor Internal refactoring of code Datetime Datetime data dtype labels Nov 28, 2020
@jreback jreback added this to the 1.2 milestone Nov 29, 2020
@jreback jreback merged commit 224d2e8 into pandas-dev:master Nov 29, 2020
@jreback
Copy link
Contributor

jreback commented Nov 29, 2020

thanks, type if possible in the future

@jbrockmendel jbrockmendel deleted the ref-wrap_datetimelike branch November 29, 2020 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Datetime Datetime data dtype Refactor Internal refactoring of code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants