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

Breaking # pyright: ignore[] used with # type: ignore[] comments on short lines #3399

Open
Avasam opened this issue Nov 30, 2022 · 3 comments
Labels
F: comments The syntactic kind. Not in the language grammar, always on our minds. Best bugs. F: linebreak How should we split up lines? T: style What do we want Blackened code to look like?

Comments

@Avasam
Copy link

Avasam commented Nov 30, 2022

Describe the style change

When validating a project with both pyright and mypy, it's possible to independently validate both checkers. (since pyright 1.1.282)
However, both expect their ignore comment to be at the start of the line.

Examples in the current Black style

line-lenght=130

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

Desired style

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

Additional context

microsoft/pyright#4243
microsoft/pyright#4259
python/mypy#12358
python/mypy#6948

@Avasam Avasam added the T: style What do we want Blackened code to look like? label Nov 30, 2022
@Avasam
Copy link
Author

Avasam commented Dec 30, 2022

pyright 1.1.283 (immediately broken in 1.1.284 and fixed in 1.1.285) added support for the first example (pyright comment at the end). I still think it'd be useful to support special comment annotations (that the user can define, to make black aware of 'em), like "pyright:", "noqa:", "nopycln:", etc.

If you don't want to support that, then I think you can close this issue.

@ichard26 ichard26 added F: comments The syntactic kind. Not in the language grammar, always on our minds. Best bugs. F: linebreak How should we split up lines? labels Jan 19, 2023
@ichard26
Copy link
Collaborator

I wonder if it makes sense to update our internal list of "sticky" comments to include the new popular tools, like pyright, pycln, etc. Not sure if that will fix this situation, but it should help in general.

@Avasam
Copy link
Author

Avasam commented Jan 19, 2023

pyright has since then allowed comments to not be at the very start. So you can have a # type ignore and a # pyright: ignore on the same line.

So now this is more about a nice to have for the "internal list of "sticky" comments to include the new popular tools", like you said.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: comments The syntactic kind. Not in the language grammar, always on our minds. Best bugs. F: linebreak How should we split up lines? T: style What do we want Blackened code to look like?
Projects
None yet
Development

No branches or pull requests

2 participants