print(DT,class=TRUE) could show type too

[mattdowle]

As Frank highlighted in #2989 (review), maybe print.data.table could show both class and typeof.
(I just did a minimal change to that PR to make progress, and created this issue to follow up in future.)

[jangorecki]

why not print(DT,typeof=TRUE) then? @MichaelChirico
as nicely explained in PR in NEWS entry, class is different from type, IMO make sense to put extra argument for that. It could even get its default from class arg to get the behaviour defined in this issue.

print.data.table(
  x, ...,
  class  = getOption("opt-for-class", FALSE),
  typeof = getOption("opt-for-typeof", class)
)

[MichaelChirico]

@jangorecki did you see the PR? #3902

Initial thought for that was a new arg but am trying with that PR to avoid if possible. If we don't think it's possible to nest the typeof info nicely along with class, then we'll split into two.

[jangorecki]

Yes I saw, that is why I came here to discuss implementation

[MichaelChirico]

Continuing discussion of implementation, I see two reasonable ways forward:

• Add a typeof= argument. Positive: clearest; Negatives: new argument, new global data.table option, requires thinking about how to do class=TRUE && typeof=TRUE
• Support class="type" or class="typeof". Basically negate the positive/negative of the above.

WDYT @jangorecki ?

[jangorecki]

class="type" doesn't sound fine, so 1st option looks better.

[MichaelChirico]

Thanks. In that case, we only need to decide about style. WDYT about just adding a new register when class==typeof==TRUE?

as.data.table(iris)
#      Sepal.Length Sepal.Width Petal.Length Petal.Width   Species
#             <num>       <num>        <num>       <num>    <fctr>
#             {dbl}       {dbl}        {dbl}       {dbl}     {int}
#   1:          5.1         3.5          1.4         0.2    setosa
#   2:          4.9         3.0          1.4         0.2    setosa
#   3:          4.7         3.2          1.3         0.2    setosa
#   4:          4.6         3.1          1.5         0.2    setosa
#   5:          5.0         3.6          1.4         0.2    setosa
#  ---                                                            
# 146:          6.7         3.0          5.2         2.3 virginica
# 147:          6.3         2.5          5.0         1.9 virginica
# 148:          6.5         3.0          5.2         2.0 virginica
# 149:          6.2         3.4          5.4         2.3 virginica
# 150:          5.9         3.0          5.1         1.8 virginica

[ben-schwen]

I would be in favor of printing type in the same row as class since vertical space is already limited

as.data.table(iris)
#      Sepal.Length Sepal.Width Petal.Length Petal.Width    Species
#         <num|dbl>   <num|dbl>    <num|dbl>   <num|dbl> <fctr|int>
#   1:          5.1         3.5          1.4         0.2     setosa
#   2:          4.9         3.0          1.4         0.2     setosa
#   3:          4.7         3.2          1.3         0.2     setosa
#   4:          4.6         3.1          1.5         0.2     setosa
#   5:          5.0         3.6          1.4         0.2     setosa
#  ---                                                            
# 146:          6.7         3.0          5.2         2.3  virginica
# 147:          6.3         2.5          5.0         1.9  virginica
# 148:          6.5         3.0          5.2         2.0  virginica
# 149:          6.2         3.4          5.4         2.3  virginica
# 150:          5.9         3.0          5.1         1.8  virginica

[MichaelChirico]

I'm not sure the example is representative -- by adding more horizontal space (the <...> part is wider than the column names only once here), we can wind up spilling past width and requiring an additional 2*nrows+3 lines of vertical space, whereas the "damage" of extra vertical space is limited to just one line if we give the types their own register.

See also the discussion in #3902 about which character to use if they share a register -- | was suggested, as were several others, with no clear consensus -- the main reason I wanted to just sidestep that issue and put it by itself.

As Jan pointed out there, knowing typeof is kinda "power user" requirement -- most people don't need to know the storage type of their columns most of the time. So only displaying it on request still makes sense to me (doesn't mean it can't be squished in next to the class summary, but it does feel more natural to me).

[just sharing further thoughts + making sure we're all on the same page about the context added by the discussion in the old PR]