Chris Lattner

Now, if I got past an integer, do some dynamic tests for it.

If it's a string, go do another thing.

There's another additional challenge, which is even if you did support overloading, you're saying, okay, well, here's a version of a function for integers and a function for strings.

Well, even if you could put it in that dictionary, you'd have to have the caller do the dispatch.

And so every time you call the function, you'd have to say, like, is it an integer or is it a string?

And so you'd have to figure out where to do that test.

And so in a dynamic language, overloading is something you don't have to have.

But now you get into a type language and, you know, in Python, if you subscript with an integer, then you get typically one element out of a collection.

If you subscript with a range, you get a different thing out, right?

And so often in type languages, you'll want to be able to express the fact that, cool, I have different behavior depending on what I actually pass into this thing.

If you can model that, it can make it safer and more predictable and faster and like all these things.

Yeah, well, this is also one of the challenges with the existing Python typing systems is that in practice, like you take subscript, like in practice, a lot of these functions, they don't have one signature.

They actually have different behavior in different cases.

And so this is why it's difficult to retrofit this into existing Python code and make it play well with typing.

You kind of have to design for that.

So here you get into what is the trade-off with the superset?

Okay.

So superset, you have to, or you really want to be compatible.

You've like, if you're doing a superset, you've decided compatibility with existing code is the important thing.

Even if some of the decisions they made were maybe not what you choose.