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

[Liz (Elizabeth King)]

@mdrissi

This specific case is both explicitly documented in pep 484 and has significant mypy primer impact. Either one of these alone would be enough to make it problematic to change without deprecation process which is difficult here to do.

Is the process linked in the post you responded to not sufficient? If not, what policy states that it isn’t?

Right now there’s another change to the behavior of this special case being considered which changes the meaning of pep 484. This change has not received the same backlash from the same people. Some people are phrasing it as only a clarification, but it changes the behavior and the thread has examples of it being or enabling a behavioral change in the very first post.

@mdrissi

TypeGuard related work with TypeIs recently is one very good example. Existing type guard semantic was documented. It was surprising for many users but it was documented and while primer impact was mild due to backwards compatibility it was decided to not be changeable.

It was also determined that TypeGuard wasn’t incorrectly specified; Users just wanted a something with other behavior.The better parallel was already shared by someone else, where things were broken on implicit optional with function parameter defaults, being changed to match what the user wrote rather than infer something beyond what they wrote in a way they could not opt out of.

The float special case on the other hand is just wrong. Int isn’t a suitable replacement when expecting a float, and the shortcut that exists in the type system is unsound.

@mdrissi

The numeric types mostly do not offer a useful nominal relationship. Basic subclass relationships don’t exist across most of them and are missing a few methods. For structural side there’s little that can be usefully said with existing abcs and adding something meaningful there breaks backward compatibility. So they’re mostly unusable classes today and fit in very badly with two type system approaches. You could invent approach 3 only for sake of numbers system, but given it’s status today would still be major lift to define reasonable rules/add stubs/hints everywhere across ecosystem.

---

Unfortunately, due to the slowmode still here, I need to post all ideas, even unrelated ones at once:

I did find a place where we can choose to be more lax:

Some type checkers early bind on inference

x = 1
x = x / 2

With the changes suggested in 1 here, any type checker early binding on inference of numeric types might have type checkers wanting to change how their inference works to either not early bind, or early bind in a permissive form, but allow specifying a more specific form that would be respected.