[chrismonsanto]

> PyPy is not fast enough and further splits the user base.

There is no split?

> Gevent is vastly simpler than this.

I prefer asyncio's explicitness to gevent's monkey-patch-and-pray-it-doesn't-block semantics. Also, the asyncio approach makes it very clear when you have released the "lock" on your state--it happens every time you yield from your coroutine. The gevent approach is to hide these synchronization points, which I think is a bad policy. For what it's worth this latter objection is one of the main reasons asyncio is the way it is--GvR had been bitten before by implicit yields.

[ekimekim]

If you're needing to think carefully on what code you call might cause a switch and what won't, you're already doing it wrong. Instead of treating gevent like coroutines with less predictable ordering, treat it like threads with more predictable ordering. You know that basic operations (eg. checking if something is a certain value, or assigning a variable) won't cause a switch. So you can do two of those in a row, without thinking about race conditions. Anything beyond that...use a lock (or a queue, or any of the other provided concurrency primitives).

[thristian]

Well, thanks to operator overloading, comparisons or assigning a variable (to a property of an object) can cause a switch. If you really need to get a mental model of what your code is doing, or could do under sufficiently unusual circumstances, gevent doesn't really provide any guarantees beyond raw threading.

Glyph (of Twisted fame) wrote a good blog-post about it: https://glyph.twistedmatrix.com/2014/02/unyielding.html

[meowface]

gevent simply has the nicer API. I've never once had an issue where the monkey patching failed, or conflicted with another library. Yes, monkey patching is a dastardly and gross thing, but in practice gevent works amazingly well for 99% of use cases.

Not to mention the performance is very good, especially in the most recent version.