Peter Van Dyken

I think it's fair not to want to spend more time on python type checking than necessary. In principle, if directly importing typing is not an option, the best solution would be to roll out .pyi files, which have 0-runtime cost. But this would involve even more work obviously. My own solution is just to use pyright's automatic type stub generation to make the type files I need for my own repository, and manually edit as necessary. This works well enough, especially since I use a fairly narrow segment...

Imports hidden within `if False:` prevents pyright from wroking

Just to expand on this, this problem occurs when unicode control character (e.g. x00-x19) (plus a few other characters including the backslash \) occurs at the site of a line break and the next line has at least one whitespace character (" "). For instance, the following values would trigger the issue: 1234567890000\x060 0 1234567890000\x030000 000000 This does not: 1234567890000\x0600 As far as I can tell, the problem occurs in emitter.py:1436-1447, code handling whether a escaped line break should...

Just to expand on this, this problem occurs when unicode control character (e.g. x00-x19) occurs at the site of a line break and the next line has at least one whitespace character (" "). For instance, the following values would trigger the issue: 1234567890000\x060 0 1234567890000\x030000 000000 This does not: 1234567890000\x0600 As far as I can tell, the problem occurs in emitter.py:1436-1447, code handling whether a escaped line break should be inserted. I can't say I understand what exactly that...