-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Truncating dispatch error message (types, instead of instances) #125
Comments
Hey @femtomc! You're totally right that this is hard to parse. The problem is that the top-level types do not always tell the whole story. For example, if a method accepts However, perhaps we can get the best of both worlds by first printing the top-level types and only appending the full arguments below. I'm thinking of something like
How would something like that look? |
Well, that looks incredible :) Do you need any help from me to support this sort of thing? Worst comes to worst, I can catch the method exception with a context handler and try to implement this myself library side. |
Technically you could even go through the various signatures to determine whether we need or not to display the type or value, and display it only if needed. By the way, I'm hoping that @wesselb will merge soon #110 which will greatly improve how errors look, so if he agrees it might be worth it to base a PR on top of that. |
Hi!
By default, it seems that
plum.resolver.NotFoundLookupError
messages are quite large e.g. I'll get errors that look like this:Now -- while all the information is there -- it's quite hard to parse. Really, what I need to see is just the toplevel types for each argument.
Is there a way to provide a global option to
plum
to ask for this type of truncation?The text was updated successfully, but these errors were encountered: