Skip to content

ENH: Added index to testing assert message when series values differ #31435

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 7 commits into from
Mar 22, 2020

Conversation

amilbourne
Copy link
Contributor

  • closes #xxxx
  • tests added / passed
  • passes black pandas
  • passes git diff upstream/master -u -- "*.py" | flake8 --diff
  • whatsnew entry

This implements the suggestion made in #31190
In short, where the values in 2 series differ, the assert exception message includes the index as well as the values. This helps when using assert_frame_equal with check_like=True, since the index may be reordered, making the output hard to understand.

Copy link
Member

@WillAyd WillAyd left a comment

Choose a reason for hiding this comment

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

Reading through your issue wouldn't you want the index of both objects to be printed? If not which index gets printed here? The left?

@WillAyd WillAyd added the Testing pandas testing functions or related to the test suite label Jan 31, 2020
@amilbourne
Copy link
Contributor Author

amilbourne commented Jan 31, 2020

@WillAyd :
The indexs are compared before the content, so if the indexs differ the changes in this PR never come into play.

If the user calls assert_frame_equal with check_like=False (the default) then the indexs must contain the same values in the same order, so they will be identical. Hence no need to specify which one is being printed.

If the user calls assert_frame_equal with check_like=True, then the indexes must contain the same values, but the order may differ. However, the field values for each index (row) must match for the frames to be considdered equal. The (existing) code reindexes one of the frames in the order of the other and then compares them. Presuming the indexes have the same values but were ordered differently then one of the frames will have its rows re-ordered. This was previously confusing in the output, as there was no indication of which rows had moved or of their new order. This PR addresses that by adding the index. Because both frames must have the same values in their index (or the code wouldn't have got as far as checking the row values), it doesn't matter which index is being used, since the row values in each frame would have had the same index value.

I hope that makes sense; I'm not sure how well I explained it there.

And thanks for looking at the PR :-)

@amilbourne
Copy link
Contributor Author

Looks like the build failure was spurious. Will hopefully vanish when I commit changes to address comments above.

@amilbourne
Copy link
Contributor Author

@WillAyd Does the description above make sense?

@amilbourne amilbourne requested a review from WillAyd February 28, 2020 22:27
@amilbourne
Copy link
Contributor Author

@WillAyd Sorry if you wanted me to make a change, but I think I have addressed your comments. GitHub still thinks there is a change requested though, and I can't figure out what I need to do to resolve it.

@WillAyd
Copy link
Member

WillAyd commented Feb 29, 2020

So IIUC this only applies to check_like because we align the index before comparing the frames, but it's not clear in case of failures what alignment was actually used, right?

@amilbourne
Copy link
Contributor Author

amilbourne commented Mar 2, 2020

@WillAyd Yes, this change is specifically intended to address an issue with index reordering if check_like=True.

The extra output (the index values) is also generated when check_like=False because it is equally valid and it keeps the output consistent, but when chec_like=False it doesn't add all that much, as the user would already know the index order. That said, the index values may make the output easier to refer to if the index is unordered or hard to remember.

@@ -917,9 +924,10 @@ def raise_assert_detail(obj, message, left, right, diff=None):
elif is_categorical_dtype(right):
right = repr(right)

msg = f"""{obj} are different
if isinstance(index, np.ndarray):
Copy link
Contributor

Choose a reason for hiding this comment

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

what does this do?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops - nothing.
Left over after refactor and should have been removed. Will remove. Thanks.

@pep8speaks
Copy link

pep8speaks commented Mar 15, 2020

Hello @amilbourne! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2020-03-21 22:09:52 UTC

@amilbourne
Copy link
Contributor Author

I just rebased this change against the latest in master to resolve the merge conflict and keep things clean. Sadly I missed a Pep 8 issue because the rebase didn't invoke the commit hooks :-/

@amilbourne
Copy link
Contributor Author

@jreback I think I have addressed all your comments but I am unsure of the etiquette here. Should I click on the 'resolve conversation' button? 2 of your comments are probably resolved (presuming my changes were what you wanted) but 1 was a question and I am unsure whether my answer is sattisfactory.

@jreback jreback added this to the 1.1 milestone Mar 19, 2020
@jreback
Copy link
Contributor

jreback commented Mar 19, 2020

lgtm. @WillAyd @jorisvandenbossche @jbrockmendel if any comments.

@jreback jreback merged commit 44de8dc into pandas-dev:master Mar 22, 2020
@jreback
Copy link
Contributor

jreback commented Mar 22, 2020

thanks @amilbourne nice addition!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Testing pandas testing functions or related to the test suite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants