Those methods (gevent and eventlet) are the default and typical way of building concurrent python services.
That article conflates threads, shared state and explicit IO awareness and dispatching. Those can be different in each case.
Python doesn't have isolated heaps like Erlang but it is still possible to have lightweight threads with a queue and not share by convention data between lightweight threads.
Having or not having @coroutines or yields or deferreds or inlineDeferreds doesn't make a difference in that case.
In general, a set of jumping callback and errback functions are a lot worse concurrency mechanism than threads.
A callback chain is a poor man's threads, it is just spread non-locally across the whole code without a way to properly synchronize.
Threads done right, should make it easy to organize data locally. This is quite the opposite of what that article claims. A set of spread around callback functions, do the opposite.
Whether yields or inlineDeferreds are used are almost orthogonal to the above. All they do is help you localize data (which callbacks don't) but now you have to explicitly care where and when you do IO. You might not even care in real life but they force you to. That is stupid.
Oh and library fragmentation. There are now 3+concurrency frameworks for Python. They all look different. And because of this bubbling of IO primitives up to the surface of the API, make it almost impossible to share libraries between them.
Those methods (gevent and eventlet) are the default and typical way of building concurrent python services.
That article conflates threads, shared state and explicit IO awareness and dispatching. Those can be different in each case.
Python doesn't have isolated heaps like Erlang but it is still possible to have lightweight threads with a queue and not share by convention data between lightweight threads.
Having or not having @coroutines or yields or deferreds or inlineDeferreds doesn't make a difference in that case.
In general, a set of jumping callback and errback functions are a lot worse concurrency mechanism than threads.
A callback chain is a poor man's threads, it is just spread non-locally across the whole code without a way to properly synchronize.
Threads done right, should make it easy to organize data locally. This is quite the opposite of what that article claims. A set of spread around callback functions, do the opposite.
Whether yields or inlineDeferreds are used are almost orthogonal to the above. All they do is help you localize data (which callbacks don't) but now you have to explicitly care where and when you do IO. You might not even care in real life but they force you to. That is stupid.
Oh and library fragmentation. There are now 3+concurrency frameworks for Python. They all look different. And because of this bubbling of IO primitives up to the surface of the API, make it almost impossible to share libraries between them.