Skip to content
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

BUG: Fix inserting of wrong-dtyped NaT, closes #27297 #27311

Merged
merged 19 commits into from
Jul 22, 2019

Conversation

jbrockmendel
Copy link
Member

Needs tests for PeriodDType case. The tests are probably not in the ideal place, how to move/parametrize them depends on what axis we want to sort them along (i.e. all Series indexing tests together or all timedelta-insertion tests together)

Copy link
Contributor

@jreback jreback left a comment

Choose a reason for hiding this comment

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

this patch is very awkward. This needs work to make it more fluid.

pandas/_libs/index.pyx Outdated Show resolved Hide resolved
pandas/core/arrays/datetimelike.py Outdated Show resolved Hide resolved
@jbrockmendel
Copy link
Member Author

this patch is very awkward. This needs work to make it more fluid.

Might be because it addresses three separate-but-related bugs. Looking at it commit-by-commit might make more sense. I'm happy to make separate PRs if that's easier

@jreback jreback added Missing-data np.nan, pd.NaT, pd.NA, dropna, isnull, interpolate Datetime Datetime data dtype labels Jul 11, 2019
@jbrockmendel
Copy link
Member Author

Rebased following #27323. This does for datetime64 Series what that did for timedelta64 Series

@jbrockmendel
Copy link
Member Author

no whatsnew, so doesnt need to be moved

@@ -2585,8 +2585,11 @@ def setitem(self, indexer, value):
try:
return super().setitem(indexer, value)
except (ValueError, TypeError):
obj_vals = self.values.astype(object)
Copy link
Contributor

Choose a reason for hiding this comment

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

do you really need to do this?

if you actually do, then .reshape(1, -1) should just work (or use np.atleast_2d)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this really is needed.

reshape(1, -1) is what is already here

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 give an example that specific needs this 2d reshape?

this just is a completely different pattern than anywhere else. Why for example would the ObjectBlock construct not simply reshape (if needed); it already knows the dim & the values shape?

@@ -2585,8 +2585,11 @@ def setitem(self, indexer, value):
try:
return super().setitem(indexer, value)
except (ValueError, TypeError):
obj_vals = self.values.astype(object)
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 give an example that specific needs this 2d reshape?

this just is a completely different pattern than anywhere else. Why for example would the ObjectBlock construct not simply reshape (if needed); it already knows the dim & the values shape?

@jbrockmendel
Copy link
Member Author

Why for example would the ObjectBlock construct not simply reshape (if needed); it already knows the dim & the values shape?

Because the Block constructor calls self._validate_ndim to check that it got the expected shape. reshaping is done earlier.

@jreback
Copy link
Contributor

jreback commented Jul 21, 2019

Why for example would the ObjectBlock construct not simply reshape (if needed); it already knows the dim & the values shape?

Because the Block constructor calls self._validate_ndim to check that it got the expected shape. reshaping is done earlier.

is this not exactly what _block_shape does?

@jbrockmendel
Copy link
Member Author

is this not exactly what _block_shape does?

It is, but block_shape gets called before the constructor.

But apparently it isnt necessary. Just ran the tests with this reshape disabled and its fine now. Will remove.

@jbrockmendel
Copy link
Member Author

removed+green

Copy link
Contributor

@jreback jreback left a comment

Choose a reason for hiding this comment

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

hmm I think this need s a whatsnew note, would do on 1.0

if not should_cast:
expected = expected.astype(object)

ser = base.copy(deep=True)
Copy link
Contributor

Choose a reason for hiding this comment

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

do these need to be deep? (no big deal though)

Copy link
Member Author

Choose a reason for hiding this comment

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

yes

@jreback jreback added this to the 1.0 milestone Jul 22, 2019
@jbrockmendel
Copy link
Member Author

whatsnew added + green

@jreback jreback merged commit 76247c1 into pandas-dev:master Jul 22, 2019
@jreback
Copy link
Contributor

jreback commented Jul 22, 2019

thanks @jbrockmendel

@jbrockmendel
Copy link
Member Author

It looks like this is causing a bunch of CI failures. cc @jreback @TomAugspurger

quintusdias pushed a commit to quintusdias/pandas_dev that referenced this pull request Aug 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Datetime Datetime data dtype Missing-data np.nan, pd.NaT, pd.NA, dropna, isnull, interpolate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG: DatetimeArray/Series incorrectly accepts timedelta64('NaT') for __setitem__
2 participants