adding left and right view to DataFrame, equivalent to head() and tail()
State: closed

I am working with a lot of columns recently and just thought of these little helpers, basically the same as head() and tail(), but for columns.
Additionally, I fixed a small pep8 issue in head()


Labels:
name: Reshaping
description: Concat, Merge/Join, Stack/Unstack, Explode
name: Output-Formatting
description: __repr__ of pandas objects, to_string
name: API Design

Comments:
ok, nice...can you add tests for them? (can just copy paste from head/tail)?

oops, my bad. will add them.

I am now using it so often, I want to have the corner cases as well:
- upperleft() = left().head()
- upperright() = right().head()
- lowerleft() = left().tail()
- lowerright() = right().tail()

What do you think?

@jorisvandenbossche ?

related #1889, #2791

I personally  think adding 6 more methods to DataFrame just for this is a bit too much. Only `left`/`right` seems better, but also not fully sure.

I think we should think a bit more carefully about this, also related to the default DataFrame display (#6547) and the issues @jreback linked to. 
Eg something like `df.show('left')`, `df.show('lowerright')`, @michaelaye would this also do? Or this maybe misses the convenience of being able to tab complete and it is not that usefull anymore this way?

Also, if the default DataFrame display will be truncated centrally (#5603), you actually already have somehow left and right in one view?

Why not have a corner method that you can pass iloc indices to? Top left would be corner(5,5) bottom left would be corner(-5,5) and so on. You could even implement head on terms of this by accepting None 

isn't this what we wanted `.show()` to be? (or was that paginated)?

Actually corner doesn't really save you anything. Nevermind

`df.show('left')` is of course quite longer than `df.left()` and not tab-completed.
But I totally agree that my feeble attempts here pale in comparison with the linked solutions. As I already noted my feeling that my hacks left me desired to have more specific views in terms of the corners, hence I find one command that can show me the corner cases extremely valuable.

To motivate this further, real-time data analysis is a lot about understanding what your current operation is doing to the data, and a quick view showing me all 4 corners goes a long way towards this. 

In this respect, if this can be implemented with one extra command and the default being to show me 2 or 3 rows or columns in the corners, I'm all for it and would recommend to reject my PR. But I also would like to stress that in terms of data visualization I would not find it wise to penny-count the number of methods, I don' think there's many more important things in data analysis than to show how it reacts to the applied operations, so IMHO it would be saving 'at the wrong end'. Nevertheless, I believe @jorisvandenbossche 's comment of 6 added methods for this was more commenting on the lack of power that my PR adds compared to the linked PRs, and here I totally agree.

So, what is the status of the centrally truncated view (i.e. a 4-corner-view), when will it come or is it available in a branch/fork?

Incidentally, I was wondering: Is it possible to automatically adapt the current automatic  number of displayed lines and columns as a percent value of the current notebook's width/length?

FWIW, I would too object about adding more "root" methods, but namespace-like `df.show.left()` seems nice, it would both support tab completion and avoid adding method clutter.

@immerrr I think that is an excellent idea!

@michaelaye if you'd like to convert this to use a `.show` namespace I think we'd take that. closing this PR in the mean-time.

What about this for a quick method hack chain???

```Python
# Display left five columns
df.transpose().head().transpose()

# Display right five columns
df.transpose().tail().transpose()
```