FIX: Fix problems with Series text representation. 
State: closed

This PR harmonizes the way DataFrame and Series are printed. 
closes #8532 
closes #7508 
Before 

```
In [1]: import pandas as pd

In [2]: pd.options.display.max_rows = 10

In [3]: s = pd.Series([1,1,1,1,1,1,1,1,1,1,0.9999,1,1]*10)

In [4]: s
Out[4]:
0    1
1    1
2    1
...
127    0.9999
128    1.0000
129    1.0000
Length: 130, dtype: float64
```

Now

```
0      1.0000
1      1.0000
2      1.0000
3      1.0000
4      1.0000
        ...  
125    1.0000
126    1.0000
127    0.9999
128    1.0000
129    1.0000
dtype: float64
```


Labels:
name: Bug
name: Output-Formatting
description: __repr__ of pandas objects, to_string

Comments:
Looks like this still needs tests to verify that the mentioned issues are fixed?

@bjonen hows this coming? 

If you want I can make the adjustments proposed by @shoyer (thanks by the way). I will not have time to do major re-factoring in the next week or two. 

@bjonen can you put in the top-section the before and after?

@bjonen also pls add a release note. I think this is pretty straight forward so don't even need an example, just put a sentence or 2 and refernce the issues. Can open another issue to address the TODO you mentioned (which can be in 0.16.0 or next version).

@bjonen I'ld like to get this in 0.16.0

can you rebase  / squash and add an example?

@jreback Example is at the top of the PR, or do you mean into the docs? I canl get this ready to go tomorrow. Hope that's early enough. 

@bjonen Yes, would be great to have this in the docs :)

ok ;). Will add the example to the docs and squash tomorrow. Glad to have this in 0.16!

Added example and rebased

@bjonen  Looks like your test changes for Categorical broke in the rebase because of #9622.

I would still love to see a unit test that verifies that the aligned display for the Series representation in the presence of truncation. This should be pretty easy to cook up, either with some explicit test cases for which you verify the entire result of `__repr__`, or with some sort of synthetic test that verifies line length, e.g.,

``` python
result = repr(s)
lines = result.split('\n')
fixed_width_lines = result[:5] + result[6:11]
assert len(set(len(line.strip()) for line in fixed_width_lines)) == 1 
```

Sure I will add this test and take out the `print` that is failing the 3.x build. 

Anything else you would like to add? 

I would still be a little happier with some explicit tests, too, just to nail down that this looks right. I would probably include cases where the string width of the series values (a) is 1, (b) is 2, (c) changes and (d) changes in descending ordering.

Also, for the width consistency test, I would cook up a bunch of synthetic series and toss them all through the same checks.

Sorry to be so insistent about testing -- but covering all your bases makes a big difference :). You don't necessarily need every last test I've suggested (use your judgment), but it is almost impossible to have too many tests, and we would like to confident that everything works properly. Generally, it's good to verify every edge case and ensure that tests exercise every line of code.

I think I've finally done that full thorough read now... :)

Thanks @shoyer for the comments. I can do this on the weekend.  What is the deadline for 0.16? 

I think @jreback wants to release a release candidate for 0.16 any day now.....

@bjonen I am going to do the rc today, but this still for 0.16.0, ping when you have updated (weekend ok)

@jreback This is ready from my side. @shoyer Thanks again for the detailed comments and no worries for insisting on adding more tests. 

lgtm, @shoyer ?

Added `header` to Series.to_string(), added test.

@bjonen thanks!

pls ping when green.

I have one style nit, but otherwise looks good to me.

@bjonen I just gave this a quick test. And in any case, this solves the original issues I reported (the wrong number of rows when truncated, and the floating point things, and the large max_rows value). Thanks for that!

But, I noticed something else now. Previously, the `...` were in the index column, now in the values. Is this change deliberate?

With this PR:

```
In [10]:  s4 = pd.Series(range(10))

In [12]: pd.options.display.max_rows = 8

In [13]: s4
Out[13]:
0    0
1    1
2    2
3    3
    ..
6    6
7    7
8    8
9    9
dtype: int64

```

In 0.15.2:

```
In [10]: s4 = pd.Series(range(10))

In [16]: pd.options.display.max_rows = 8

In [17]: s4
Out[17]:
0    0
1    1
...
8    8
9    9
Length: 10, dtype: int64
```

It is just an observations, I am not yet sure what I like most. For dataframes with put dots in both the index column and values:

```
In [14]: s4.to_frame()
Out[14]:
    0
0   0
1   1
2   2
3   3
.. ..
6   6
7   7
8   8
9   9

[10 rows x 1 columns]
```

And a last thing: could you also add a test that tests the second bullet point in #8532: when setting `pd.options.display.max_rows` at something larger than 60 had no effect (but that is fixed now with your PR!)

That's a fair point. While consistent with `DataFrame`, having the dots in both index and data for a `Series` looked like overkill to me. That's why it is only in one. I don't have a strong preference where to put it (index or values). You prefer to keep it in the index as in 0.15? 

@bjonen thanks for this! you are formatting expert!

as usual, pls look at the built docs (give it a couple of hours) and confirm that they look look ok.!