Internal error on "showing value of type Base.MethodList" #24195
Comments
|
While I believe we can fix this on our end (note to self: seems to be due to dispatch on types containing free variables), please do not define methods like these: This redefines how types get printed, which can interfere with many things in the system such as printing method tables. While these particular definitions are very simple, if they were more complicated and had bugs, you (and other users of the package) could end up in a situation where you can't debug anything since nothing can be printed. The term "type piracy" gets thrown around, but I've taken to calling this kind of case "type treason". |
|
Hi Jeff, |
|
Yes, correct. |
|
Note also that you should almost never override |
|
Update: after removing the While I still feel that user code should not cause internal errors, it would be okay for me to close this. |
|
I recently ran into a similar problem. If overloading |
|
Is it okay to define |
|
I believe only providers of displays should define I guess it's slightly less bad to define a |
|
I was hoping for |
|
Example? |
|
Yes, I guess defining |
|
Basically we want a type alias to show up as its alias rather than the underlying UnionAll. |
|
This is now supported: help?> Base.showarg
showarg(io::IO, x, toplevel)
Show x as if it were an argument to a function. This function is used by summary to display type information in terms of sequences of function calls on objects. toplevel is true if this is
the direct call from summary and false for nested (recursive) calls. |
|
|
|
It will probably help mitigate the downside though, thanks |
|
Never mind, it doesn't apply here. Why does Base need |
@JeffBezanson could you clarify this statement? Should we be avoiding defining methods such as More specifically I'm looking into making a type similar to julia> struct TZ{name} end
julia> macro TZ_str(name)
:(TZ{$(Expr(:quote, Symbol(name)))})
end
@TZ_str (macro with 1 method)
julia> TZ"A/B"
TZ{Symbol("A/B")}I'd like to avoid the extra verbosity present when using julia> Base.show(io::IO, m::MIME"text/plain", T::Type{TZ}) = print(io, "TZ")
julia> function Base.show(io::IO, m::MIME"text/plain", T::Type{<:TZ})
name = T.parameters[1]
if name isa Symbol
print(io, "TZ\"$name\"")
else
invoke(show, Tuple{IO, MIME"text/plain", Type}, io, m, T)
end
end
julia> TZ"A/B"
TZ"A/B"
julia> TZ
TZ
julia> TZ{1}
TZ{1}However, the main use for this is as a type parameter for another type. That means that using julia> struct ZDT{T <: TZ} end
julia> ZDT{TZ"A/B"}
ZDT{TZ{Symbol("A/B")}}Looking into the code julia> Base.show(io::IO, T::Type{TZ}) = print(io, "TZ")
julia> function Base.show(io::IO, T::Type{<:TZ})
name = T.parameters[1]
if name isa Symbol
print(io, "TZ\"$name\"")
else
invoke(show, Tuple{IO, Type}, io, T)
end
end
julia> ZDT{TZ"A/B"}
ZDT{TZ"A/B"}
julia> ZDT{TZ}
ZDT{TZ}
julia> ZDT{TZ{1}}
ZDT{TZ{1}}So far this implementation seems to work great but it's definitely very easy to mess up method printing if you aren't careful in how you define these methods. Is there a path forward on custom show methods for user defined types? Should we add official support for this via a new function (e.g. |
|
If you add an incorrect definition for show on a Type, such as the one you posted there, things will break: don't do that! Closing, as I am not seeing too much actionable in this issue right now. In particular, we may want to fix the issue where we may dispatch an improper type as if it was a subtype of a proper type, but I don't think this issue reflects that in a way which would enable us to find this issue when we fix that. |
|
@vtjnash my main questions was not answered:
I understand the impact given the current behaviour of Base, but I cannot see a reason why the current behaviour is necessary. Is |
|
What is the purpose of defining |
|
I've added the triage label as I think a quick conversation could clear some things up. |
|
From triage: all we can really do is recommend that people not define this, or be very careful if they do. |
Hi,
while trying to prepare my package for julia-0.7, I encountered a situation where calling an ambiguous method leads to an internal error. Even fixing the ambiguity, I get an internal error when calling
methodson the function in question. Unfortunately I haven't been able to produce a minimal example, as I can't trigger the internal error when substantially removing methods from the function.This session shows how the bug can be triggered:
v0.6 of julia doesn't exhibit this behavior, it just shows all the methods.
Thanks.
The text was updated successfully, but these errors were encountered: