Printing of time-related types in containers is inconsistent

[tkf]

I think #30817 changed show(io, "text/plain", ::Array{Day}) etc. On cb7a569 (and in Julia 1.0 and 1.1) it was:

julia> Day.(1:3)
3-element Array{Day,1}:
 1 day
 2 days
 3 days

But now (c0e9182) it's:

julia> Day.(1:3)
3-element Array{Day,1}:
 Day(1)
 Day(2)
 Day(3)

Furthermore, confusingly (to me), Matrix{Day} still prints human readable form:

julia> [Day(1) Day(2)]
1×2 Array{Day,2}:
 1 day  2 days

However, @omus and others approved the following behavior in #30200:

julia> fill(d, 2)
2-element Array{Date,1}:
 Date(2018, 12, 7)
 Date(2018, 12, 7)

julia> fill(d, 2, 2)
2×2 Array{Date,2}:
 2018-12-07  2018-12-07
 2018-12-07  2018-12-07

So maybe the current behavior of Vector{Day} and Matrix{Day} is intentional? (But, to be honest, I was confused why ndims of an array changes how elements are printed.)

Another confusing part is that show(io, ::Array{Day}) still shows human-readable form. Shouldn't it closer to repr than 3-argument show?

julia> show(Day.(1:2))
Day[1 day, 2 days]

Note that the output of Dict{Day,Day} and Vector{Pair{Day,Day}} are not changed. It has been (and is):

julia> Dict(Day(1) => Day(2))
Dict{Day,Day} with 1 entry:
  1 day => 2 days

julia> [Day(1) => Day(2)]
1-element Array{Pair{Day,Day},1}:
 1 day => 2 days

What is the intended printing behavior of Day, Date, and alike in the containers?

See also: #30683

[nalimilan]

Matrix printing sets :compact=>true, vector printing doesn't. And indeed since #30817 show checks for that property to decide the printing format. That's doesn't make a lot of sense to me since both representations take the same number of characters. What @JeffBezanson suggested in that PR was to change repr to use Day(1), but still print 1 day from show, but that's not what's been implemented.

What we could also do is check the :typeinfo property of IOContext, and if it's equal to Day, print only the number, without the mention of the unit. That would give a super compact printing in most arrays and in data frames.

Cc: @fchorney

[JeffBezanson]

We should remove the branch that switches to 1 day based on the :compact property. We can optionally add typeinfo support as well.

[nalimilan]

@tkf Would you make a pull request?

[tkf]

I think I can make a PR, but I need to understand the desired output.

If we check :typeinfo and only print a number, show(Day.(1:2)) would prints Day[1, 2], right? But this can't be evaluated now because Base.convert(::Type{Day}, ::Int) is not defined. Should we still print Day[1, 2] here?

Branching on :compact seems to be added to show human-readable format in DataFrame #30200 (comment). But my guess is that the fix should go into DataFrames.jl. It seems that DataFrames.jl is using 2-arg show to pretty-print the element: https://github.com/JuliaData/DataFrames.jl/blob/8d75d7464bdea76bb394081f66d870b2d9bf1c3b/src/abstractdataframe/show.jl#L20-L30 I suppose it should be using show(IOContext(io, :compact=>true, :typeinfo=>typeof(x)), "text/plain", x). So, is it OK to temporary break DataFrame printing?

Likewise, Base.print_matrix_row also uses 2-arg show for elements even though print_matrix_row is called from 3-arg show for an array.

julia/base/arrayshow.jl

Line 104 in 62c411d

sx = sprint(show, x, context=io, sizehint=0)

It seems to me that it should be using 3-arg show with :compact => true. This also applies to other container types like Dict.

(All my above comments are based on the assumption that changing show is considered a "minor change".)

[nalimilan]

I guess we can defer the :typeinfo change for now, since convert(::Type{Day}, ::Int) may be controversial. Though I'm not sure whether the output of show is always supposed to be parseable (I guess @JeffBezanson knows?).

Regarding the two-argument vs. three-argument show, AFAIK arrays should use the two-argument method, as the three-argument one is for multiline printing.

[tkf]

Though I'm not sure whether the output of show is always supposed to be parseable (I guess @JeffBezanson knows?).

I already asked him this in #30757. His answer (#30757 (comment)) was:

I should add that we are not really strict about show output needing to be parseable. I think the reason for that is that I don't really see many use cases for parseable output, but I could be wrong. If there are contexts where parseable output is really important, we indeed might need to add a new thing for guaranteed parseable output.

So maybe Day[1, 2] is OK?

two-argument vs. three-argument show

I think there are three concepts and only two methods. Ideally, it's nice to have:

• (a) Human-readable multi-line text representation.
• (b) Human-readable short text representation (which is used by containers).
• (c) Parse-able or at least Julia code-like (?) text representation.

3-arg show does (a) and 2-arg show has to do (c) as that's how repr works. The question is what function should do (b). If we let 2-arg show do (b) and (c), it's very tricky to have nice 3-arg show for Array{MyType} (see e.g., https://discourse.julialang.org/t/18951). That's why I suggested in #30757 (comment) to add MIME"application/julia" to the convention so that we can decouple (b) and (c). Alternatively, as I mentioned in the previous comment, letting 3-arg show handle (b) with :compact => true would also decouple them.

[nalimilan]

TBH I'd rather not discuss the redesign of the printing system here as it's really beyond the scope of this issue. Feel free to file another issue if you have a detailed proposal.

So maybe Day[1, 2] is OK?

Why not. Though as a data point, Unitful.jl represents arrays of values with units like this (which is not parseable):

julia> show(fill(1Unitful.m, 2))
Quantity{Int64,𝐋,Unitful.FreeUnits{(m,),𝐋,nothing}}[1 m, 1 m]

So the equivalent would be "[1 day, 1 day]". It would make sense to use the same convention in Base and in Unitful (in either direction). Cc: @ajkeller34

[omus]

So maybe Day[1, 2] is OK?

I personally don't like this as it appears to be valid Julia code but it isn't. Since we already decided that convert(::Type{Day}, ::Integer) is a non-sensical conversion we may want to instead use Day.([1, 2]) as it is almost as terse but is parsable. I'm also fine with [1 day, 2 days].

Branching on :compact seems to be added to show human-readable format in DataFrame #30200 (comment). But my guess is that the fix should go into DataFrames.jl

I like this idea. Can we implement the fix for DataFrames first?

[JeffBezanson]

I personally don't like this as it appears to be valid Julia code but it isn't.

Agree.

Actually I will partly retract my previous comment --- with the printing system as it is now, using :compact to select the human-readable output for show seems like a reasonable solution. I think most of the blame here falls on the fact that 3-arg show for 1-d arrays doesn't touch :compact, but all other ways of printing arrays set :compact=>true. I have actually never liked that. repr and show should not set :compact --- I think that's a bug --- and I'd prefer for 3-arg show to always set it.

[fchorney]

@nalimilan
My apologies. It was my understanding that the output was fine as far as print, string, repl, and show were concerned, except that we still wanted “1 day” to appear in the REPL when declared.

[nalimilan]

we may want to instead use Day.([1, 2]) as it is almost as terse but is parsable.

We can't print Day.([1, 2]) since we only control the printing of individual entries here.

Branching on :compact seems to be added to show human-readable format in DataFrame #30200 (comment). But my guess is that the fix should go into DataFrames.jl

I like this idea. Can we implement the fix for DataFrames first?

What do you want to fix in DataFrames? AFAICT it uses show just like printing vectors does.

[omus]

What do you want to fix in DataFrames?

At the moment nothing needs to change. If we decide to move away from using the compact show to display the human-readable output then it would be good to adjust DataFrames behaviour so it can continue to show the human-readable output.

[nalimilan]

I don't think DataFrames should diverge from vector printing.