Treat triple-quoted type annotation expressions as implicitly parenthesized

[erictraut]

I would like to request that the typing council consider a clarification to the typing spec with regard to the proper behavior of a triple-quoted (forward reference) type annotation expression.

For details, refer to this discussion.

Here's a PR with the proposed spec language change: https://github.com/python/typing/pull/1578.

The proposed behavior is consistent with pyright's current behavior. Mypy 1.8.0 doesn't behave this way, but the next version of mypy will include this commit which allows it to conform to the prescribed behavior.

Pyre and pytype do not currently conform to this behavior, so they would need to make small changes to implement it.

• [x] Eric
• [x] Guido
• [x] Jelle
• [x] Rebecca
• [x] Shantanu

[gvanrossum]

Is this truly linked to the triple quote syntax? What if a single quote is used but \n' (or\x0a` etc.) occurs in the string? There appear to be discrepancies between type checkers around this as well as around string literal concatenation. (E.g. a triple-quoted string with escaped line ends is acceptable to mypy but not to pyright -- it seems the latter doesn't "evaluate" string literals at all, whereas mypy does.)

[erictraut]

Yes, there are many other things that are under-specified here: questions about string literal concatenation, escaped characters, raw strings, literal bytes, f-strings, etc.

I'm open to pinning down the standard for any or all of these if we think there's a good reason to do so, but I'd prefer to do those separately from the triple-quote issue.

The triple-quote one came up recently in a pyright bug report, so I took that as evidence that there was a legitimate use case and a desire for conformance between type checkers. For the other items in this list, I can remember only one question about string concatenation in the past, and I don't think any of the others have come up before.

If we are looking to pin down the specification for the other items in this list, I'd prefer to make them illegal. I can't think of a good use case, and they are problematic for language servers that need to specify precise text ranges for diagnostics (so the "red squiggle" can appear in the correct place). They also add significant complexity and ambiguity for completion suggestion behavior.

[gvanrossum]

That's fair. I think the new rule for triple-quoted strings is fine (though I don't think I've ever had a use case).

[hauntsaninja]

PR to spec merged: https://github.com/python/typing/pull/1578