Skip to content

Make DTA _check_compatible_with less strict by default #30721

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
Jan 6, 2020

Conversation

jbrockmendel
Copy link
Member

One of the two non-cosmetic things mentioned in #30720.

There are a bunch of places where DTA or DTI do a compatibility check that for tz_awareness_compat, but not requiring the same tz. This check is analogous to PeriodArray._check_compatible_with and TimedeltaArray._check_compatible_with, so this adds a kwarg to _check_compatible_with so that we can use _check_compatible_with in all the relevant places and subsequently de-duplicate a bunch of code.

In addition to the comparisons, this is going to be relevant for searchsorted and insert, where we have slightly different behavior in a bunch of EA/Index subclasses.

@@ -123,6 +123,9 @@ def _check_compatible_with(
Parameters
----------
other
strict : bool, default False
For __setitem__ we may have stricter compatiblity resrictions than
Copy link
Contributor

Choose a reason for hiding this comment

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

don’t we always need to check this for date times? why do u actually need a keyword

Copy link
Member Author

Choose a reason for hiding this comment

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

ATM we dont use _check_compatible_with in the DTA comparison ops, but after this we will be able to.

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 call this something else besides strict as this only applies to DTI, maybe check_tz (and ignore this elsewhere). i know strict is more generic, but also very confusing.

Copy link
Member Author

Choose a reason for hiding this comment

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

changed "strict"->"setitem"

@gfyoung gfyoung added Algos Non-arithmetic algos: value_counts, factorize, sorting, isin, clip, shift, diff Datetime Datetime data dtype labels Jan 6, 2020
@jbrockmendel
Copy link
Member Author

updated+green

@jreback jreback added this to the 1.0 milestone Jan 6, 2020
@jreback jreback merged commit bebaff0 into pandas-dev:master Jan 6, 2020
@jbrockmendel jbrockmendel deleted the ref-compatible branch January 6, 2020 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Algos Non-arithmetic algos: value_counts, factorize, sorting, isin, clip, shift, diff Datetime Datetime data dtype
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants