-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Remove builtins.
from error messages
#5072
Comments
I think they should be already removed from almost everywhere (if not, this is a bug). The only place that shows all names full is the error for overloads. I think this is the one we need to fix first. |
|
Yes, but TBH I think overloads are still more important, |
There's a couple of others:
|
Oh wow, this would be quite some work to clean-up. Also this needs to switch to using double quotes probably |
Part of #5072. Overloads are probably the most common user-facing feature that still outputs "builtins" in error messages; this diff fixes them to use standard type formatting. I also change builtins.None to None, since builtins.None is a syntax error. A comment claimed that we use builtins.None to distinguish the type from the value, but I don't think there are a lot of contexts where that confusion is likely.
Closes python#5072, follows up to python#11490
Our error messages would be a bit more concise if we removed the
builtins.
part from type output, and perhapstyping.
too. This would make error messages match up more closely with runtime syntax.For example, we currently output
None
asbuiltins.None
, which is a syntax error at runtime. Just outputtingNone
would be more clear.The text was updated successfully, but these errors were encountered: