-
Notifications
You must be signed in to change notification settings - Fork 770
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
78 permanent errors in builtins.pyi
#6409
Comments
Yes, these are real type errors in Typeshed maintainers are forced to use incompatible method overrides because the stdlib does not always honor the Liskov Substitution Principle. The typeshed CI pipelines explicitly disable a number of pyright's checks including reportIncompatibleMethodOverride and reportPrivateUsage. If you would prefer that these errors be suppressed, you could submit a bug report or a PR to the typeshed project to add |
Hi @erictraut, As per Jelle's response, those errors should not be showing up. Is there a way I can configure pyright to not show them? I tried various ways of adding the file to my Regards, |
Jelle is correct that if you run the pyright CLI tool on your project, you should not see errors in stub files or library files that are imported but are not themselves part of your project. Likewise, if you are using the pyright language server (or pylance) and open files that are part of your project, you won't see errors from However, if you explicitly open |
Ah, I see where the confusion is. I am not opening |
Ah, interesting. If you're seeing these all the time even when |
Thanks Eric! |
@tylerlaprade It would be helpful for us to be able to repro this on our own machines. Could you provide the following:
|
@StellaHuang95, I unfortunately cannot share my repo since it's company property, and I haven't seen this repro in a "simple" case. I did include my I was unable to past the logs because it is too many characters. |
You should be able to save the log to a file and then just drag it into the issue. That should tell us where the builtins.pyi errors are coming from. |
It only repro'd when you opened the file? I would guess that's this error then: VS code doesn't always tell us that a file has closed. That can cause errors from recently opened files to remain visible until you restart VS code. |
Yes. Although that's different behavior from last week - it was previously reporting errors without opening anything. |
It's also possible there's another condition responsible for getting me into the "always error" mode which I'm unaware of. I just forced the trigger for the logging. |
Update: I just experienced the 78 errors without opening
|
Unfortunately, it needs the trace logging on. We must have analyzed the builtins.pyi for some reason. |
I have noticed this issue happening frequently recently. I suspect it might be caused by other VSCode extensions, as I recently added GitHub Pull Requests and GitLens to my setup. |
I'm also seeing errors persist after I close a source file, not necessarily with builtins.py. I've confirmed in the debugger that VS Code is sometimes not sending a "file closed" message to the language server, or it sends it in a delayed manner, tens of seconds after the file was actually closed. I've tried disabling other VS Code extensions to see if they might be the cause, but that doesn't seem to be the problem. I suspect it's a regression in VS Code itself. I started to see this about two months ago. |
@wxMichael, that's great info, thanks. I use both those extensions. I assume GitLens would be the culprit, although it could be either. |
Environment data
v2024.9.100 (pre-release)
orv2024.14.1
(occurs with both)Code Snippet
pyrightconfig.json
Expected behavior
No errors from outside my code
Actual behavior
The text was updated successfully, but these errors were encountered: