Multiline syntax that is normally invalid is accepted inside stringized annotations.

[elenakrittik]

Describe the bug
Multiline syntax that is normally invalid is accepted inside stringized annotations.

Code or Screenshots
If possible, provide a minimal, self-contained code sample (surrounded by triple back ticks) to demonstrate the issue. The code should define or import all referenced symbols.

from typing_extensions import TypeAlias


Alias1 = (
    int
    | str
    | bool
)  # parentheses required

Alias2: TypeAlias = """
    int
    | str
    | bool
"""  # mypy: Invalid type comment or annotation  [valid-type]
     # ruff (a linter): [F722] Syntax error in forward annotation
     # pyright: 0 errors, 0 warnings, 0 informations

VS Code extension or command-line
Command line, 1.1.345

[erictraut]

Hmm, that was a conscious decision I made when writing pyright's parser. The meaning seems unambiguous to me if you've enclosed the type expression in quotes. Pyright treats a triple-quoted type expression as though it's implicitly parenthesized.

Is there a reason you want this to generate an error? I can understand why mypy would generate an error here, since it's using Python's built-in parser, which is pretty limited and rigid.

If there's a good reason for rejecting this, I'm willing to make the change in pyright. I'm not yet convinced there's a good justification, however.

[elenakrittik]

Hmm, that was a conscious decision I made when writing pyright's parser. The meaning seems unambiguous to me if you've enclosed the type expression in quotes. Pyright treats a triple-quoted type expression as though it's implicitly parenthesized.

Is there a reason you want this to generate an error? I can understand why mypy would generate an error here, since it's using Python's built-in parser, which is pretty limited and rigid.

If there's a good reason for rejecting this, I'm willing to make the change in pyright. I'm not yet convinced there's a good justification, however.

Honestly, i am only happy that it works the way it works. I was not absolutely sure this wouldn't cause issues in more bizarre case, so i decided to open a ticket.

As a library author one of my big concerns is supporting all conformant type checkers, and (unluckily, in my horrible opinion) mypy is one of them. This means that even if pyright supports this, when developing libraries i will still have to add parentheses so that mypy and others do not complain.

I (maybe unfortunately) don't have a strong opinion on what to do in this case. Logically, this should be "fixed" (as pyright technically accepts invalid syntax here, and other tools agree that this is an error), but at the same time i would love to have this as an option when developing end applications. Maybe others can weight in their opinions.

[erictraut]

Interestingly, mypy appears to accept invalid syntax here too — in a slightly different manner. It allows you to add leading carriage returns, which would not be permitted outside of triple quotes.

# Allowed by mypy
Alias2: TypeAlias = """



    int
"""

There is value in having consistent behavior between tools in the ecosystem, so that might be sufficient justification. I'll pose the question to the broader typing community and see what they think.

[erictraut]

Here's the discussion topic if you want to follow along: https://discuss.python.org/t/newlines-within-triple-quoted-type-expressions/42833.

[erictraut]

As a library author one of my big concerns is supporting all conformant type checkers

We're making good strides toward improving conformance across type checkers. There is now an official (although not yet comprehensive) typing spec, and I've been contributing to a new conformance test. You can see the latest conformance results for the four major type checkers here. If there are other aspects of the typing spec that you think should be standardized, please post your thoughts to the python/typing forum.

[elenakrittik]

Right, thank you. I didn't mean that "supporting all conformant type checkers" is challenging for me, it's only something that i keep eyes on when encountering "interesting" cases like this, sorry if i miscommunicated. You and others do a great job on keeping typings consistent!

[erictraut]

It sounds like the consensus is that pyright's approach here is preferable. A PR has been submitted to mypy so its behavior matches. I'll try to get this added to the official typing spec and conformance test suite as well.

I'm going to close this ticket since there's no required change to pyright in this case.

[erictraut]

@charliermarsh, you may also be interested in this thread, as ruff currently considers this a syntax error.

[charliermarsh]

(Thanks @erictraut! We’ll update our parser.)