Comment by Groxx

3 months ago

To try to tl;dr that rather long post:

> When you add type hints to your library's arguments, you're going to be bitten by Hyrum's Law and you are not prepared to accurately type your full universe of users

That's understandable. But they're making breaking changes, and those are just breaking change pains - it's almost exactly the same if they had instead done this:

    def slow_add(a, b):
        throw TypeError if !isinstance(a, int)
        ...

but anyone looking at that would say "well yeah, that's a breaking change, of course people are going to complain".

The only real difference here is that it's a developer-breaking change, not a runtime-breaking one, because Python does not enforce type hints at runtime. Existing code will run, but existing tools looking at the code will fail. That offers an easier workaround (just ignore it), but is otherwise just as interruptive to developers because the same code needs to change in the same ways.

---

In contrast! Libraries can very frequently add types to their return values and it's immediately useful to their users. You're restricting your output to only the values that you already output - essentially by definition, only incorrect code will fail when you do this.