[red-knot] how should assert_type handle the float/complex special case?

[carljm]

Description

We follow the typing spec and other type checkers in implementing the special case that a float annotation means int | float, and a complex annotation means int | float | complex.

We don't currently follow other type checkers in trying to "hide" this special case by revealing just float or complex when the actual type we have is int | float or int | float | complex. Doing this leads to very strange-looking behaviors, like this from pyright:

def _(x: float):
    reveal_type(x)  # float
    if isinstance(x, float):
        reveal_type(x)  # float
    reveal_type(x)  # float | int ??

But this leads us to fail this type assertion:

assert_type(3.14, float)

Because we interpret float there as a type expression, meaning we take it to be int | float, but we actually infer just float for the literal.

[InSyncWithFoo]

I think float should be interpreted as int | float no matter the context. That helps with consistency.

Instead, knot_extensions should export BareFloat and BareComplex as public APIs for such use cases (credits go to @sharkdp):

type BareFloat = TypeOf[1.0]
type BareComplex = TypeOf[1j]