Skip to content
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

Closed
5 tasks done
erictraut opened this issue Jan 13, 2024 · 4 comments
Closed
5 tasks done
Labels

Comments

@erictraut
Copy link
Collaborator

erictraut commented Jan 13, 2024

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.

  • Eric
  • Guido
  • Jelle
  • Rebecca
  • Shantanu
@gvanrossum
Copy link
Member

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
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Collaborator

PR to spec merged: python/typing#1578

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants