-
-
Notifications
You must be signed in to change notification settings - Fork 3
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
Treat triple-quoted type annotation expressions as implicitly parenthesized #9
Comments
Is this truly linked to the triple quote syntax? What if a single quote is used but |
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. |
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). |
PR to spec merged: python/typing#1578 |
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: python/typing#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.
The text was updated successfully, but these errors were encountered: