Guido van Rossum

That's just the fact of life.

I didn't account for what should happen in that case in the way I told the story.

And so what we actually have to do is when we have the add integer operation, we still have to check...

Are the two arguments in fact integers?

We applied some tricks to make those checks efficient.

And we know statistically that the outcome is almost always, yes, they are both integers.

And so we quickly make that check and then we proceed with the sort of add integer operation.

And then there is a fallback mechanism where we say, oops, one of them wasn't an integer.

Now we're going to pretend that it was just the fully generic add operation.

We wasted a few cycles believing it was going to be two integers, and then we had to back up.

But we didn't waste that much time, and statistically, most of the time.

Basically, we were sort of hoping that most of the time we guessed right, because if it turns out that we guessed wrong too often,

or we didn't have a good guess at all, things might actually end up running a little slower.

So someone armed with this knowledge and a copy of the implementation, someone could easily construct a counterexample where they say, oh, I have a program and now it runs five times as slow in Python 3.11 than it did in Python 3.10.

But that's a very unrealistic program.

That's just like an extreme fluke.

I think that the heuristic is actually, we assume that the weather tomorrow is going to be the same as the weather today.

That is already so much better than guessing randomly.

Python is not the first language to do a thing like this.

This is a fairly well-known trick, especially from other interpreted languages that had reason to be sped up.