# Options for a long term fix of the special case for float/int/complex

**URL:** <https://discuss.python.org/t/options-for-a-long-term-fix-of-the-special-case-for-float-int-complex/54289>\
**Category:** Typing\
**Created:** [May 26, 2024, 2:57pm UTC](https://discuss.python.org/t/options-for-a-long-term-fix-of-the-special-case-for-float-int-complex/54289 "2024-05-26T14:57:23Z")\
**Posts on this page:** 1\
**Showing post:** 172

<div class="post-metadata">

**Author:** ![jamesdow21](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesdow21/32/34808_2.png) [@jamesdow21](https://discuss.python.org/u/jamesdow21)\
**Post date:** [July 8, 2025, 8:25pm UTC](https://discuss.python.org/t/options-for-a-long-term-fix-of-the-special-case-for-float-int-complex/54289/172 "2025-07-08T20:25:40Z")

</div>

> [@tmk](#):
>
> This is, I think, what PEP 484 says (that `int` should be a subclass of `float`), but I think Eric Traut from pyright wanted to change it.

The exact language from [PEP 484](https://peps.python.org/pep-0484/#the-numeric-tower) is

> when an argument is annotated as having type `float`, an argument of type `int` is acceptable; similar, for an argument annotated as having type `complex`, arguments of type `float` or `int` are acceptable.

There is also this example from the [“Subtype relationships” section of PEP 483](https://peps.python.org/pep-0483/#subtype-relationships)

> A more formal example: Integers are subtype of real numbers. Indeed, every integer is of course also a real number, and integers support more operations, such as, e.g., bitwise shifts `<<` and `>>`:
> 
> ```python
> lucky_number = 3.14 # type: float
> lucky_number = 42 # Safe
> lucky_number * 2 # This works
> lucky_number << 5 # Fails
> 
> unlucky_number = 13 # type: int
> unlucky_number << 5 # This works
> unlucky_number = 2.72 # Unsafe
> 
> ```

(note: variable annotations were not supported until later with PEP 526, so this is using the special type comments)

From those two, it’s clear that the _behavior_ of a type checker should be that an `int` can be assigned to a variable annotated as `float` or passed to a function argument annotated as `float`, but it doesn’t actually specify _how_ that behavior should be implemented.

mypy uses heuristics that kind of treat `int` as a subclass of `float` but not always, while pyright moved to mostly doing the approach of “`float` in a type expression actually means `float | int`”

There had already been [an issue](https://github.com/python/mypy/issues/11516) on the mypy issue tracker that suggested moving to that union approach. Carl Meyer (who has been working on Astral’s new type checker `ty`) opened [an issue](https://github.com/python/typing/issues/1746) on the `typing` GitHub asking that the typing specification be clarified.

Jelle Zijlstra [proposed](https://github.com/python/typing/pull/1748) that the typing specification be modified to explicitly specify the union approach, which mostly matches existing type checker results and the conformance test suite that goes along with the typing specification. He then [opened a thread here on Discuss](https://discuss.python.org/t/clarifying-the-float-int-complex-special-case/54018) about that change, which then prompted _this_ very discussion thread.

---

_[View the full topic](https://discuss.python.org/t/options-for-a-long-term-fix-of-the-special-case-for-float-int-complex/54289)._