Guido van Rossum

It was very prevalent in JavaScript at the time, at least, because it was like how the JavaScript event loop basically works.

And so I thought, well, the task-based model where each task has a bunch of logic, we had mechanisms in the Python language that we could easily reuse for that.

And I thought, I want to build a whole library for asynchronous networking I.O.,

and all the other things that may need to be done asynchronously based on that paradigm.

And so I just chose a paradigm and tried to see how far I could get with that.

And it turns out that it's a pretty good paradigm.

The global interpreter lock...

solves the problem that Python originally was not written with either asynchronous or parallelism in mind at all.

There was no concurrency in the language, there was no parallelism, there were no threads.

Only a small number of years into Python's initial development,

All the new cool operating systems like SunOS and Silicon Graphics IRIX and then eventually POSIX and Windows all came with threading libraries.

that lets you do multiple things in parallel.

And there is a certain sort of principle, which is the operating system handles the threads for you.

And the program can pretend that there are as many CPUs as there are threads in the program.

And those CPUs work completely independently.

And if you don't have enough CPUs, the operating system sort of simulates those extra CPUs.

On the other hand, if you have enough CPUs, you can get a lot of work done by deploying those multiple CPUs.

But Python wasn't written to do that.

And so...

As libraries for multithreading were added to C, but every operating system vendor was adding their own version of that.