Type annotation which is dynamic variable

[amacfie]

for t in [str, float]:
    def f(x: str) -> t:
        return t(x) + 1
    print(f("3.14"))

Pyright finds no errors in this. Is there different type syntax I should use or is this outside of Pyright's scope?

[erictraut]

Yeah, this should be flagged as an error.

The challenge for a type checker is in distinguishing between an implicit type alias and variables that are not meant to be type aliases.

For example, this is legal and the use of u in this type annotation should not be flagged as an error.

u = str
for t in [str, float]:
    def f(x: str) -> u:
        return t(x) + 1

    print(f("3.14"))

Pyright uses some heuristics that attempt to distinguish between a valid (implicit) type alias and a normal variable. Those heuristics are failing in this case, resulting in a false negative.

I'll clone this discussion as a bug report.

[erictraut]

This will be fixed in the next release.

[amacfie]

Thanks, that would be great. Mypy currently disallows using the t name from the above examples as a type annotation (docs). Perhaps when you make the changes you could document how Pyright and Mypy differ in this regard.

[erictraut]

To be clear, with my recent change, pyright will also disallow this. So mypy and pyright will be in agreement in this regard. No difference to document. :)

[amacfie]

Oh, ok, that's not what I was hoping!

[erictraut]

Variables cannot be used as type annotations. Type aliases can be used as type annotations, but differentiating between a variable and a type annotation can be challenging because they use the same syntax. In your example, t is clearly a variable and not a type alias, so mypy is correct to flag these as errors, and pyright will do so as well.

[amacfie]

After the change, the following generates a type error

t: type[str] | type[float]
for t in [str, float]:
    def f(s: str) -> t:  # error: Illegal type annotation...
        return t(s)
    print(f("3.14"))

However, the following does not

def outer(t: type[str] | type[float]):
    def f(s: str) -> t:
        return t(s)
    print(f("3.14"))

t: type[str] | type[float]
for t in [str, float]:
    outer(t)

(And indeed if we have t(s) + 1 instead of t(s), Pyright says Operator "+" not supported for types "str | float" and "Literal[1]".)

So @erictraut, should function arguments also be illegal or is this a valid use of types?

[erictraut]

Yes, function parameters are the same as local variables in this respect. Neither are allowed in type annotation expressions.

You said that the second code sample above isn't resulting in an error for you? It is for me. Is this different from what you're seeing?

[amacfie]

Oh, weird

$ cat t.py
def outer(t: type[str] | type[float]):
    def f(s: str) -> t:
        return t(s)
    print(f("3.14"))

t: type[str] | type[float]
for t in [str, float]:
    outer(t)

$ pyright t.py
...
Assuming Python version 3.10
...
Found 1 source file
pyright 1.1.293
0 errors, 0 warnings, 0 informations 
...

(empty config)

[erictraut]

This change wasn't in 1.1.293, so unless you're building pyright yourself, you won't see this fix until next week's release (1.1.294).

[amacfie]

Ok, thanks.

Yes, function parameters are the same as local variables in this respect. Neither are allowed in type annotation expressions.

So we can do

class Animal: ...
class Snake(Animal): ...

T = TypeVar('T', bound=Animal)

def make_animal(animal_type: type[T]) -> T:
    a: T = animal_type()
    return a

but not

...

def make_animal(animal_type: type[T]) -> T:
    a: animal_type = animal_type()
    return a

Correct?