-
-
Notifications
You must be signed in to change notification settings - Fork 18k
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
TST: add copy/view test for setting columns with an array/series #47070
TST: add copy/view test for setting columns with an array/series #47070
Conversation
Yes, should be fixed now! |
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.
lgtm
cc @jbrockmendel @mroeschke if comments
def test_set_column_with_series(using_copy_on_write): | ||
# Case: setting a series as a new column (df[col] = s) copies that data | ||
df = DataFrame({"a": [1, 2, 3], "b": [4, 5, 6]}) | ||
s = Series([1, 2, 3]) |
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.
nitpick s->ser pls
assert not np.shares_memory(df["c"].values, s.values) | ||
|
||
# and modifying the series does not modify the DataFrame | ||
s.iloc[0] = 0 |
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.
could also assert s.iloc[0] == 0
, as failure for that to hold would be another way the next assertion could pass
nitpicks, otherwise LGTM. i really liked the comments @jorisvandenbossche ! |
Thanks @jorisvandenbossche |
…das-dev#47070) * TST: add copy/view test for setting columns with an array/series * Update pandas/tests/copy_view/test_setitem.py * address feedback
Similarly as #46979, this is adding some test cases explicitly testing copy/view behaviour for a specific topic: if we set an array or series as a column, is the new column a copy or a view of the original data?
At this moment, we actually already do make a copy of that data (with one exception being the cached RangeIndex values). So the tests I added here are confirming that current behaviour in tests, and adding a few checks where Copy-on-Write could delay the copy.