RFC: make default module-prefix showing independent of the state of Main(e)

[JeffBezanson]

Currently, whether module prefixes are included in type name representations depends on what you have using'd in Main. This is not good. For example:

julia> module Foo
       using Sockets
       f() = repr(IPv4)
       end

julia> Foo.f()
"Sockets.IPv4"

julia> using Sockets

julia> Foo.f()
"IPv4"

In other words, behavior of code in some random place depends on what you happen to have loaded in your session. The idea behind this (more concise object representations at the REPL) makes sense, but I believe it should be implemented by setting the :module IOContext variable instead of by making Main the default.

With this change, both outputs above are "Sockets.IPv4", but the type is still shown as just IPv4 in the REPL.

[nalimilan]

Clever!

[nalimilan]

Makes sense. Can you confirm it won't affect e.g. the output of doctests in Documenter manuals?

[JeffBezanson]

Documenter will have to be updated to pass the :module property.

[StefanKarpinski]

This change had the advantage of making long spellings of names that are available at the REPL much shorter, which this PR does away with. Have you actually encountered people being really confused by this or is th is more of a theoretical concern? I have not personally found that people are confused by the fact that what’s available in the current session affects how things are displayed in that session.

[JeffBezanson]

This is not supposed to affect how things are displayed --- that can be retained by having the REPL set the :module property on its output stream, which is what that property is for AFAIK. Read the example in the OP carefully. If, say, some package code tries to stringify something, what it gets depends on the state of the user environment.

[timholy]

I agree with this principle. Seems likely to be breaking, though; perhaps test ImageCore would be worth a spin?

[JeffBezanson]

Yes, this will probably break some package tests. One major cause I've found so far is calls to summary(x) that need to be summary(io, x). There are a bunch left over since summary used to be 1 argument only.

[StefanKarpinski]

Right, I see what you're getting at and wholeheartedly agree that this printing shouldn't change based on what's imported into an unrelated module. I think this can be fairly legitimately argued to be a bug fix, albeit one which may cause some breakage. We'll have to be sure the breakage is fixed.

[JeffBezanson]

Next major hazard: print(io, "T = $T") and print(io, "T = ", T) are not equivalent, since in the first case converting T to a string cannot see the context from io (of course this has always been the case, but this change exposes it more). I swear I did not intend this to be about string interpolation :) Anyway, those forms probably appear equivalent to many so it's a bit of a gotcha. I'm not sure what if anything to do about it.

[StefanKarpinski]

I swear I did not intend this to be about string interpolation :)

Likely story

[StefanKarpinski]

Triage notes that triage two weeks ago talked about this extensively and then wrote nothing down. Way to go triage from two weeks ago!

[jonas-schulze]

Could https://discourse.julialang.org/t/making-code-available-to-workers/71462 be related to this? I mean, would something like this also make module.jl work?