But fundamentally, the GIL prevents Python from being used as a systems language. This is only true when severely restricting the definition of a systems langu

But fundamentally, the GIL prevents Python from being used as a systems language. This is only true when severely restricting the definition of a systems language. The vast majority of command line utilities you'll find in a typical operating system are often primarily I/O-bound or do not have critical performance requirements. As such, I'd only be willing to agree with the author's statement for a very specific subset of systems programming. For example, I've worked on a packaging system written in Python for the last five years or so. The package system is primarily I/O-bound the vast majority of the time (waiting on disks or network), and almost all significant performance wins (some as much as 80-90%) have come from algorithmic improvements rather than rewriting portions in C (very little is written in C). As one of my colleagues is fond of saying (paraphrasing), "doing less work is the best way to go faster". It also ignores the fact that depending on the problem space involved, there may be readily available solutions that provide excellent performance that don't involve threading (e.g. the multiprocessing module, shared memory, etc.).