Issues like this need to be filed over at https://github.com/python/typing rather than on this issue tracker. Perhaps @JelleZijlstra or @gvanrossum can transfer it over.

Having said that, while I agree in principle with many of your points, I doubt we'll be changing this. It's been this way for many years now, and changing it now would be very breaking for a large number of users.

@AlexWaygood Thank you and sorry for the incorrect filing of this issue.

I agree that this has been part of Python since the beginning of support of typing. It would be a big BC break (affecting also all my projects).

I was thinking about sending a PR to mypy that would "fix" this using an optional switch. But then I realised that because of how the PEP484 is phrased, it would be incorrect to disallow assigning int to float. Maybe there's a way it could be rephrased so that it would allow for such option in Mypy? In current state, my PR would be almost certainly rejected.

While your premise it true, a float is not an int. I don't think this has a chance. The PEP 484 decision was intentional and pragmatic. It reflects what is done in a lot of real world code (functions that accept floats also accept ints). And subsequent to the PEP being approved, the decision proved to be useful in practice.

To change the decision would require broad discussion and buy in and perhaps another PEP. If you want to pursue that route, I recommend starting a discussion on the forums. Just expect that it will be an uphill battle. The original decisions wasn't made lightly.

I agree with what was said above, but a few more thoughts:

• mypy could add an option to disable the int/float (and complex/float) promotion, but one complication would be that typeshed stubs are written under the assumption that float includes int. So it would have to continue to apply the promotion when checking calls to stdlib functions.
• You raise a good point about methods that exist on float but not int. Let's see if we can resolve those differences:
  • int.is_integer could be added with the trivial behavior of always returning True. This seems harmless to me but others may have objections; feel free to open an issue requesting it be added. A similar precedent is complex.__complex__, which was added in Should we define complex.__complex__ and bytes.__bytes__? #68422.
  • float.fromhex is a classmethod. If we added int.fromhex and made it accept the same format as float.fromhex, it would have to return a float, which would be weird for an int classmethod; and if it accepted a different format, we wouldn't actually help int/float interoperability.
  • float.hex returns a hex representation that is specific to floats, and it would be weird to have this method on ints but return a float-specific representation.

• int.is_integer could be added with the trivial behavior of always returning True. This seems harmless to me but others may have objections; feel free to open an issue requesting it be added. A similar precedent is complex.__complex__, which was added in Should we define complex.complex and bytes.bytes? #68422.

I'd be happy to see this added, and I agree it would lessen some of the pain here. Another precedent is the way that int objects have fairly pointless imag and real properties. I believe this is purely so they conform a little more closely with the numeric tower in the numbers module, which specifies that Integral numbers are a subtype of Complex numbers:

>>> x = 5
>>> x.real
5
>>> x.imag
0

Int is supposed to be duck type compatible with float. So yes, it should have all (instance) methods of float.

Yes, fromhex() is an alternative constructor and a classmethod, so is much less relevant to LSP concerns.

I think there's consensus that is_integer should be added to int. This is safe, straightforward and has precedent with the complex attributes, like Alex mentions. I agree that we should leave hex alone.

This is brought up somewhat regularly on mypy's issue tracker. I think there's a little bit of an XY complaint happening here in that the actual behaviour that static typing users get confused by is isinstance(1, float) is False — and users don't actually really care about the is_integer method. Note that mypy's behaviour has recently started to reflect the runtime more accurately (see python/mypy#13781 ), which should help with these complaints.

OP also provides a split_whole_and_decimal example, but I don't find that compelling since float.__str__ will happily spit out 1e+20

For history, see also issue #70867 and the reverted PR #6121.

@hauntsaninja Do you have bandwidth to make a corresponding PR for adding is_integer to fractions.Fraction? (decimal.Decimal is more involved, and might be better left to another day).