ENH: raise_assert_detail only shows the difference between the columns
State: closed

- [x] closes #47910 
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature. The change is super small so I figured it didn't really make sense to add it to the `whatsnew` section but if I should still do this please let me know 

I didn't receive feedback on whether or not it was okay to make this the default behavior but doing so minimizes the code impact and is a reasonable default in my opinion so I'm submitting it like this. If this needs to e changed feel free to let me know. 

Labels:
name: Testing
description: pandas testing functions or related to the test suite

Comments:
I'll be honest aside from the linting one I have no idea why these checks failed. A lot of them seem to fail on parts that I haven't even touched. Could anyone help me understand what's going wrong here? 
Hello @savente93! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:





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

##### Comment last updated at 2022-08-14 07:56:35 UTC
@MarcoGorelli Thanks for your direction earlier. I've reverted the original behavior and added a conditional flag for this and added a test. Most of the CIs pass now but a lot of them also fail because of this error:
```
 Error: The runner has received a shutdown signal...' in GHA. GH 45651
```

I'll be honest I have no idea what this is and have also been unable to find any information on it. Have you seen this before perhaps? Mind giving me another hint? Thanks! 
> 

Hey - I haven't had a chance to review the PR yet, but that error looks unrelated, if you fetch and merge upstream/main and push again then I presume it'll go away
it did indeed, thanks so much! 
I agree that `atol` and `rtol` should be used, I'll take a look at that later. However, I would really strongly prefer the current solution if at all possible for a couple of reasons: 

1. The solution you propose doesn't actually solve the problem in my use case. It's not just that the statement doesn't print the actual difference but also that it prints so a massive amount of redundant information that the output becomes unreadable. The current solution would solve both of these problems
2. the other problem is that as far as I can tell adding these things to the default behavior would break all the current tests which you instructed me to not do previously.  
3. this is a subjective point I'll fully admit but I find that pytest notation very intuitive to read and it often trips me up. I find the way it currently displays things much clearer so I'd like to keep the current way if at all possible. 

I don't mean to be difficult, but for the reasons above I'd like to keep the current solution if possible. Is there a reason you're opposed to adding an argument? 
You can already hide the output by setting `max_seq_items` to something small, like `1` e.g.
```
with pd.option_context('display.max_seq_items', 1):
    assert_frame_equal(df1,df2)
```
(as an aside - it looks like setting `0` doesn't work, so that's a separate bug, I'll open an issue for this)

Then, with the solution I'm suggesting, you'd get
```
DataFrame.iloc[:, 0] (column name="a") values are different (0.27397 %)
[index]: [2022-01-01T00:00:00.000000000, ...]
[left]:  [1.0, ...]
[right]: [1.0, ...]
At index 2022-12-31T00:00:00.000000000 diff: 1.0 != 0.0
```

As for adding an extra argument - it adds complexity, you'd need extra testing to check how it interacts with all the other arguments already there (e.g. currently, it wouldn't interact well with `rtol` and `atol`).

---

I'm open to making the current output more readable, especially in your case when the elements themselves are quite long, but I do think it's a separate issue to only showing elements where the frames differ
If that's your position then I don't think this PR is actually the right way to go about it, so I'll be closing it. Thanks for your consideration and help along the way.