psf / black

The uncompromising Python code formatter
https://black.readthedocs.io/en/stable/
MIT License
38.62k stars 2.43k forks source link

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

Open Avasam opened 1 year ago

Avasam commented 1 year ago

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

https://github.com/microsoft/pyright/issues/4243 https://github.com/microsoft/pyright/issues/4259 https://github.com/python/mypy/issues/12358 https://github.com/python/mypy/issues/6948

Avasam commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.