Forbid extremely long line lengths in non-autogenerated stubs

[Avasam]

It simply isn't true that stub authors don't have control over making lines shorter. Unless it's in a stub where we avoid manual changes (ie: proto stubs). Or extremely rare cases like long URLs or import aliases. 130 characters is already very generous, and I think we're better off respecting that limit.

Most of these were caused by manual comments and type: ignore which black avoids moving to not trigger mypy errors, but which are easy to move manually.

[Akuli]

I'm not a big fan of this:

• For someone not deeply familiar with details of Python's syntax, this is much more magical than the previous long one-liner.
• This is fragile and easy to mess up. Move the backslash or add indentation, basically touch it in any way, and it's not the same string anymore. Some changes affect inspect.cleandoc() while others do not.

If we're extremely concerned about long strings for some reason, can't we just run black with --experimental-string-processing (or a non-deprecated alternative if it exists and works)?

[Avasam]

We use multiline strings and multiline implicit concatenations for a handful of @deprecated

If you have concerns about using multiline strings here, maybe we could review our usage and change the ones in pywin32 stubs to multiline ISC.

I'm really not a fan of multiline ISC, as they look like multiple arguments, rather than the same strings. But with the tooling we have in place, ISC errors can be caught. Whilst to your point, accidental trailing whitespace changes in multiline strings can't and are more likely to happen.

[Akuli]

I'm no longer convinced that multiline strings are the worst solution. Each alternative has its own problems:

• multiline strings: need to look at indentations carefully (indentation is included in the string)
• ISC: need to pay attention to commas and middle spaces (if you want "foo bar" then these are all wrong: "foo" "bar", "foo " " bar", "foo ", "bar")
• long lines: not nice in editors unless you enable word wrap

[Avasam]

Just as a note:
"foo " " bar" can be caught by https://docs.astral.sh/ruff/rules/single-line-implicit-string-concatenation/ (multiline ISC is one thing, but there's really no reason for single line ones). Unless you meant multiline ISC, but were just being concise in your example

"foo ", "bar" should be caught by mypy and pyright

[Avasam]

@Akuli Are you fine with the current state of this PR or would you like to first discuss this further ?

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[Akuli]

I still think long strings are slightly nicer (though not much nicer) than multiline strings. But apparently I'm the only maintainer who feels that way, so you can merge as far as I'm concerned :)