Is int always a subclass of float in Pyright?

[mmerlo]

Pyright (strict mode) does not report any issues when returning an int when a float is expected. See get_float() in the example below:

class Test:
    def __init__(self) -> None:
        pass

    def get_int(self) -> int:
        return int(1)

    def get_float(self) -> float:
        return self.get_int()

This appears to be the intended behavior based on this statement on Static Typing: Advanced Topics:

This is a legal assignment because int is considered a subclass of float

Is there a way to turn off this assumption so that pyright gives a error when an int is assigned to a float? One thought was to use numpy types instead, but I'd prefer to stick with the builtin types if possible.

[erictraut]

Your question isn't really a "pyright" question as much as a "Python type system" question. The Python typing spec dictates how type checkers must interpret a float type annotation, and pyright is conformant with the spec. Even though int is not a subclass of float at runtime, the type expression float is interpreted as float | int by static type checkers. Similarly, the type expression complex is interpreted as complex | float | int.

There is currently no way in the Python type system to specify a type that is "only a float but not an int". There has been some discussion about this in the typing forum.

I don't think it would work to reinterpret float to have this meaning, even as an configuration switch in a type checker. There's simply too much code (including all of the typeshed stdlib stubs) that assume the current meaning. We'd need to define a new way to "spell" this type in an annotation. The best idea I've heard so far is to create a new special form typing.Float (note the capital letter F) that has this meaning. If you're interested in pursuing something like this, I recommend responding to that typing forum thread or starting a new one. I think there's some support within the typing community for such a feature, but there's also healthy skepticism about whether such an extension to the type system is justified. You'd need to make a compelling case for it. A feature like this would require a new PEP.

[mmerlo]

Thanks. That really helps. I'm fairly new to typing in Python so the extra background is appreciated.

I noticed that bool also appears to be a subclass of float (see get_float_2() below which is also not detected by Pyright under strict mode). Is this also the intended behavior? I don't see this mentioned in the Python typing spec nor the discussion in the typing forum you linked to.

class Test:
    def __init__(self) -> None:
        pass

    def get_int(self) -> int:
        return int(1)

    def get_float(self) -> float:
        return self.get_int()

    def get_float_2(self) -> float:
        return True

[erictraut]

Yes, this is intended behavior. bool is not a subclass of float, but it is a subclass of int. That means it's assignable to the type float | int, which is implied by the type annotation float.

In most use cases, it's beneficial for an int or bool value to be assignable to a float. This makes sense because almost all of the same operations that can be performed on a float can be performed safely on an int or bool object. That's why the type system treats float and complex annotations specially. There are a few exceptions, but they are extreme edge cases and generally don't appear in real-world code. I'm curious why you want to disallow this assignability. Is there a type safety issue that you're concerned about?

[mmerlo]

In my specific case, I'm using a dict to pass keyed values that can be of either float | int | bool. The dict is populated by multiple functions that return the correct type for each key. Ultimately, these values will be serialized to "c-friendly types" to be sent to a microcontroller. I'd prefer the typing system catch situations where, for example, a bool was assigned to a key that should be a float, which is clearly an error in my implementation.

Do you have any suggestions on how this may be implemented differently?

[erictraut]

Yeah, the type system isn't designed for this use case. There's no way in the type system to enforce that a value must be an instance of a particular class, unless that class is marked @final and therefore cannot be subclassed. The int class is not @final, so it can be (and is) subclassed.

Here's an idea that you may want to explore. You could create custom classes that wrap float, int, and bool values. The constructor for each class could validate (at runtime) that the value is actually an instance of the appropriate class. You could then use these wrapper types as annotations in your code. Users would need to call a constructor to allocate one of these wrapper instances. This may be more cumbersome than you'd like.

[mmerlo]

Thanks Eric. This has been very helpful. I'll prototype your custom classes idea and see how it works out. Thanks again!