Type "floating[Any]" is not assignable to return type "T@f"

[allanleal]

The following code produces a reportReturnType error:

import numpy as np
from typing import Any, TypeVar

T = TypeVar('T', bound=np.floating[Any])

def f(x: T) -> T:
    return x**2

The solution is to cast the result of x**2 to type(x): type(x)(x**2)

However, I was expecting that pylance would infer that x**2 has a compatible type to T and thus no type cast would be needed.

Is this behavior expected? Is there an anything I can do to avoid the explicit cast?

[erictraut]

Yes, this behavior is expected.

Pyright (the type checker that pylance is based on) is not using inference in this case. It's applying type evaluation rules dictated by the Python typing spec and the type information provided by the numpy library.

The numpy library indicates that the floating.__pow__ magic method (which is invoked when you use the ** operator) returns a value of type floating. That means if T is a subclass of floating, the return result of __pow__ would not be the same as T. I don't know enough about this class to say whether this type information is correct or this is a bug in the numpy library. If you think it's a bug, please consider reporting it to the maintainers of numpy. If the __pow__ method is supposed to return an instance that shares the same class as its operands (some subclass of np.floating), then its return type should be Self rather than floating.

[allanleal]

Thanks for clarifying. The lack of inference is happening even in the simplest case of multiplication of x: T by 2.0. I also removed dependency on numpy.floating, replacing it with float:

Thus, not specific to __pow__ nor numpy.floating. Do you think this should be addressed in pyright/pylance?

I'd prefer to stick with the strict mode of pylance but this issue is making the code very cumbersome with multiple unnecessary explicit type conversions throughout.

[erictraut]

As I said above, there is no inference going on here. Pyright is simply applying standard type evaluation rules. There's nothing to "address" here because pyright is behaving correctly as a static type checker. If we were to change its behavior as you're suggesting, it would no longer be compliant with the Python typing spec, and it wouldn't correctly reflect what happens at runtime.

Let's take a closer look at the example above where you're using multiplication with a value whose type is described by a type variable with an upper bound of float. The * operator invokes the float.__mul__ method. The type information for this method can be found in the builtins.pyi type stub file, part of the community-maintained typeshed project that tells static type checkers how they should evaluate stdlib behaviors. If you type float.__mul__ in your editor and then right-click on __mul__ and choose "Go to Declaration", you will see the typeshed declaration for this method. Here's a link to that line in the typeshed repository. You'll see that the return type is float, not Self. That means this method will always return a float even if it is invoked on a subclass of float.

We can confirm that this accurately reflects the runtime behavior by running the following program.

class MyFloat(float):
    pass

f1 = MyFloat(1.0)
f2 = MyFloat(2.0)

f3 = f1 * f2
print(type(f1)) # MyFloat
print(type(f2)) # MyFloat
print(type(f3)) # float

[allanleal]

Got it. Thanks. I was under the impression that T with bound=float would only permit float values, but that is not the case:

Therefore, x is not always necessarily float in 2.0 * x and the result needs to be explicitly cast to satisfy the static type checking system.

[allanleal]

@erictraut Thanks again for taking the time to explain. It turns out that what I want is a definition of T without bound:

from typing import TypeVar
from numpy import float32, float64

T = TypeVar('T', float, float32, float64)

def f(x: T) -> T:
  return 2 * x

This causes no problems with the static type checking system.