You are right, GIL isn't an issue with I/O-bound tasks.
The article didn't limit its focus to I/O, though. It felt more like an explanation of modern concurrency and asynchronous options in Python (besides just threading and and multiprocessing).
The only practical issue with the GIL in Python is that it forces you to use new (heavy) Python processes to parallelize computationally heavy tasks. Not so much of a concern depending on your application, but it is a gotcha for people new to Python.
The real issue, though, as your parent poster mentioned, is the number of different ways to access asynchronicity and concurrency in modern Pythons. It really does run counter to Python PEP20 [0] and can lead to some communication difficulties among developers.
Just an aside from the argument here, I think almost no python API actually follows the zen of python. It's certainly a nice idea, just incredibly hard to actually live upto in the real world.
Comments
You are right, GIL isn't an issue with I/O-bound tasks.
The article didn't limit its focus to I/O, though. It felt more like an explanation of modern concurrency and asynchronous options in Python (besides just threading and and multiprocessing).
The only practical issue with the GIL in Python is that it forces you to use new (heavy) Python processes to parallelize computationally heavy tasks. Not so much of a concern depending on your application, but it is a gotcha for people new to Python.
The real issue, though, as your parent poster mentioned, is the number of different ways to access asynchronicity and concurrency in modern Pythons. It really does run counter to Python PEP20 [0] and can lead to some communication difficulties among developers.
[0] https://www.python.org/dev/peps/pep-0020/
Just an aside from the argument here, I think almost no python API actually follows the zen of python. It's certainly a nice idea, just incredibly hard to actually live upto in the real world.