tibble printing

[patperry]

A few minor suggestions, feel free to ignore. I'm trying to give constructive criticism here, but other people may feel differently and I don't want to start a flame war.

Here's the print output from the latest dev version of tibble:

> as_tibble(mtcars)
# A tibble: 32 x 11
     mpg   cyl  disp    hp  drat    wt  qsec    vs    am  gear  carb
 * <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl> <dbl>
 1  21.0  6.00   160 110    3.90  2.62  16.5  0     1.00  4.00  4.00
 2  21.0  6.00   160 110    3.90  2.88  17.0  0     1.00  4.00  4.00
 3  22.8  4.00   108  93.0  3.85  2.32  18.6  1.00  1.00  4.00  1.00
 4  21.4  6.00   258 110    3.08  3.22  19.4  1.00  0     3.00  1.00
 5  18.7  8.00   360 175    3.15  3.44  17.0  0     0     3.00  2.00
 6  18.1  6.00   225 105    2.76  3.46  20.2  1.00  0     3.00  1.00
 7  14.3  8.00   360 245    3.21  3.57  15.8  0     0     3.00  4.00
 8  24.4  4.00   147  62.0  3.69  3.19  20.0  1.00  0     4.00  2.00
 9  22.8  4.00   141  95.0  3.92  3.15  22.9  1.00  0     4.00  2.00
10  19.2  6.00   168 123    3.92  3.44  18.3  1.00  0     4.00  4.00
# ... with 22 more rows

1. The # A tibble: 32 x 11 header is really distracting for people who aren't familiar with tidyverse. If I produce a report for a non-R person using, say, Rmarkdown, they aren't going to want to see # a tibble everywhere. ("I ran the following regression, and here are the results: # A tibble...). I realize that this information is helpful for programmers, but isn't it a better use of the space to display an extra row of data?

2. Again, I see why it's nice for the programmer, but it seems unnecessary to display the types. Most of the time, I would rather see more data.

3. Don't make me add. When I want to know how many rows there are in a table, my natural reflex is to look at the bottom-left corner. In the example above, I would do 10 + 22 in my head. I realize that the 32 is already in the header, above, but I have not managed to train myself to look there first. How about changing the footer to # ... 32 rows total? When necessary do # ... 32 rows total; with 3 more columns: x, y, z

A lot of this comes down to deciding who you're trying to optimize the display for. Is it for the programmer? If so, then the current display works nicely. If you have a different audience in mind, you might want to change the default printing. My personal choice would be to have the print method optimized for a potentially non-technical client, but then to also provide a schema function that prints type information, optimized for the programmer.

Let me emphasize that I am not trying to start a flame war here. Reasonable people can disagree with these opinions.

[patperry]

For comparison, here's how printing works for a corpus_frame:

library(corpus)
> structure(mtcars, class = c("corpus_frame", "data.frame"))
                     mpg cyl  disp  hp drat    wt  qsec vs am gear carb
Mazda RX4           21.0   6 160.0 110 3.90 2.620 16.46  0  1    4    4
Mazda RX4 Wag       21.0   6 160.0 110 3.90 2.875 17.02  0  1    4    4
Datsun 710          22.8   4 108.0  93 3.85 2.320 18.61  1  1    4    1
Hornet 4 Drive      21.4   6 258.0 110 3.08 3.215 19.44  1  0    3    1
Hornet Sportabout   18.7   8 360.0 175 3.15 3.440 17.02  0  0    3    2
Valiant             18.1   6 225.0 105 2.76 3.460 20.22  1  0    3    1
Duster 360          14.3   8 360.0 245 3.21 3.570 15.84  0  0    3    4
Merc 240D           24.4   4 146.7  62 3.69 3.190 20.00  1  0    4    2
Merc 230            22.8   4 140.8  95 3.92 3.150 22.90  1  0    4    2
Merc 280            19.2   6 167.6 123 3.92 3.440 18.30  1  0    4    4
Merc 280C           17.8   6 167.6 123 3.92 3.440 18.90  1  0    4    4
Merc 450SE          16.4   8 275.8 180 3.07 4.070 17.40  0  0    3    3
Merc 450SL          17.3   8 275.8 180 3.07 3.730 17.60  0  0    3    3
Merc 450SLC         15.2   8 275.8 180 3.07 3.780 18.00  0  0    3    3
Cadillac Fleetwood  10.4   8 472.0 205 2.93 5.250 17.98  0  0    3    4
Lincoln Continental 10.4   8 460.0 215 3.00 5.424 17.82  0  0    3    4
Chrysler Imperial   14.7   8 440.0 230 3.23 5.345 17.42  0  0    3    4
Fiat 128            32.4   4  78.7  66 4.08 2.200 19.47  1  1    4    1
Honda Civic         30.4   4  75.7  52 4.93 1.615 18.52  1  1    4    2
Toyota Corolla      33.9   4  71.1  65 4.22 1.835 19.90  1  1    4    1
⋮                   (32 rows total)

Note also that I'm displaying 20 rows instead of 10. I want to display as much data as possible. A standard terminal has 24 rows, and I'm using all of them: 1 for the command, 1 for the header, 20 for data, 1 for the footer, 1 for the prompt

[krlmlr]

Thanks. I agree that with 22 more rows should probably be with 32 rows total instead. The data types and the header are covered by #170, but the data types are now handled in the pillar package, so we need to consider this when finalizing its API. To cover your use case, we also need options to configure the printing behavior. Happy to review a PR.

There's glimpse() that displays one row of text per column, similarly to str().

[patperry]

Probably won't have time for a PR for awhile, too busy with my day job. I've already put too much time into this package :)

[jeroenjanssens]

I think it's great that effort is being made towards improving the readability of tibbles.

There's one thing that I'm not sure about, though, and that's using "T" and "F" instead of "TRUE" and "FALSE" for logicals. Maybe it's just me, but I find it more difficult to quickly distinguish between these two characters than the complete words. Interestingly, "T" and "F" are also considered bad coding style: https://github.com/rdatsci/PackagesInfo/wiki/R-Style-Guide ;)

I guess we could do a couple of things here:

• Revert back to TRUE and FALSE
• Add an option to disable the new printing style for logicals
• Add color

These are just some thoughts. I'm curious to hear what others are thinking.

PS. I'm extremely grateful for the tidyverse and friends. Without it, I would have probably given up on R!

[krlmlr]

@jeroenjanssens: Would you mind opening an issue in pillar?

@patperry: #364 is about improving documentation for implementation of print() methods (including hiding the data type). We decided to keep the current layout (header and footer) for now, but this should be tweakable for subclasses.

[patperry]

Makes sense. It's tough to innovate in the space because people have strong opinions about visual design. It's impossible to make everyone happy. Keep up the good work!

[krlmlr]

Thanks. Logicals are now printed as TRUE and FALSE in the most recent version of pillar.

[jeroenjanssens]

Thanks @krlmlr !

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.