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

Typing
23

I can imagine a few ways here, but none of them are going to be easy or happen immediately.

I’m quite averse to breaking users without warning or reason. I believe we have a reason to fix this (but that it would break users). If option 1 is viable, it’s then how do we ensure this is surfaced to users.

for what it’s worth, this should not break any runtime users:

>>> isinstance(1, float)
False

As for communicating this to users with enough time, I’m not sure what’s considered enough time for typing changes like this, I don’t think we’ve had anything with this large a potential impact since typing became as widely adopted as it is.

I can come up with a few ways this could be done, but I was more focused on convincing that it’s a problem effecting people, and that a further bandaid (like options 2-4) are likely just as disruptive as fixing it properly. I’ll admit that this approach did not strongly address all of the concerns vs the status quo as a first priority.

Some quick ideas, but I would want to think through this more:

  1. type checker per project setting “I am ready for numeric tower changes” that if set, type checkers should not warn for bare use of float or complex
  2. Announcement as part of a python release
  3. Informational pep
  4. Run it in the typeshed, mypy-primer, pyright-primer and reach out to libraries.
1 Like