Skip to content
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

How to report unnecessary pyright: ignore comments, but not type: ignore ? #4243

Closed
Avasam opened this issue Nov 28, 2022 · 6 comments
Closed
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request

Comments

@Avasam
Copy link

Avasam commented Nov 28, 2022

Is your feature request related to a problem? Please describe.
I would like pyright to report unecessary pyright: ignore comments. But completely leave alone type: ignore in libraries I'm validating against both mypy and pyright.

The following config still reports Unnecessary "# type: ignore" comment

"reportUnnecessaryTypeIgnoreComment": "error",
// Leave `type: ignore` comments to mypy
"enableTypeIgnoreComments": false,

With "enableTypeIgnoreComments": true, any # type: ignore[whatever] will disable all pyright errors for that line. And will also report if added to a line with a mypy-only error-code.

Describe the solution you'd like
A way for pyright to stop checking # type: ignore comments completely. (but not pyright: ignore)

@Avasam Avasam added the enhancement request New feature or request label Nov 28, 2022
@erictraut
Copy link
Collaborator

I'm reluctant to add such a feature because it's effectively working around a limitation in mypy. Mypy should provide its own way of suppressing diagnostics (a # mypy: ignore comment).

I think it's reasonable to suppress the reportUnnecessaryTypeIgnoreComment diagnostics if enableTypeIgnoreComments is set to false. That gives you the option of disabling enableTypeIgnoreComments entirely, treating all # type: ignore as though they didn't exist. I've made that change, and it will be included in the next release.

@erictraut erictraut added the as designed Not a bug, working as intended label Nov 29, 2022
@Avasam
Copy link
Author

Avasam commented Nov 29, 2022

I agree about mypy and I've upvoted the issue you linked.

Thank you!

@erictraut erictraut added addressed in next version Issue is fixed and will appear in next published version and removed as designed Not a bug, working as intended labels Nov 29, 2022
@erictraut
Copy link
Collaborator

This is addressed in pyright 1.1.282, which I just published. It will also be included in a future release of pylance.

@Avasam
Copy link
Author

Avasam commented Nov 30, 2022

Thanks! It mostly work but there's still 1 edge case: if a mypy and pyright error do happen on the same line. I can't ignore both because both expect their ignore to be at the start of the comment.
Same line doesn't even necessarily mean same error. But certain formatters (like black), will force everytihing on a line until the set limit.

Example:

class Task(Future[_T_co], Generic[_T_co]):  # type: ignore[type-var]  # pyright: ignore[reportGeneralTypeIssues]
  # [...]
  pass
 
// OR
class Task(Future[_T_co], Generic[_T_co]):  # pyright: ignore[reportGeneralTypeIssues]  # type: ignore[type-var]
  # [...]
  pass

And I have a hunch due to discussions in python/mypy#12358 that mypy isn't the one that's gonna be able to support ignores at the end of the line.
This could also be an issue with other tools that want their special keywords at the start of the line.

@Avasam
Copy link
Author

Avasam commented Nov 30, 2022

Alternatively a pyright: ignore-next-line or block disable/enable would also work.

@erictraut
Copy link
Collaborator

I consider this ticket closed. If you have additional feature requests, please open a new ticket.

We're unlikely to implement "next line" or block disable. That has been suggested before and has been rejected. You could search for that issue and upvote it. We sometimes reconsider decisions if a closed issue has been upvoted by many pyright users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version enhancement request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants