No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.
It seems like you not only misunderstand the question, but felt the need to question their intelligence and give a rude, vague, and overall unhelpful answer. As a piece of communication, it is overall useless to everyone involved. Please be mindful of the way you come across. There's no need to insult, dismiss and disrespect others. It only takes a single moment, and saves time and energy for both you and them. You could rephrase like "No. You can approach this to a level of <percentage_of_perf>, but it will be hard to pass that point, due to the way the library is written." If you did that, you'd add some very valuable information to the conversation with little effort. It would be a win win for everyone.
Beyond that, assuming your benchmarks are accurate, this seems like a prime library for someone to write a python wrapper for! There's autobahn-twisted right now, but I'm not sure how well it performs in comparison.
My intentions were not to harm, that was why I said "no offence, but". I cannot more than explain myself. Sorry if I offended anyone (despite explicitly saying "no offence"). Someone should probably censor me, like, a lot.
I doubt you are trying to harm anyone. But you're not being very helpful. You say that you've "landed on someone's holy ground" but there is a very low chance that is going on. They probably just want to get a job done, and they want to figure out if your tool's a good fit. All it takes is a little bit more thought before you type out a response.
I'm not telling you to censor yourself. I'm telling you to stop worrying about explaining yourself, and start thinking about being more helpful. I'm telling you to do it, because it will make things easier for you. You might have written the library, but other people are going to be the ones who use it. They're going to ask you questions, and you're going to think some of those questions are stupid. It's okay. But if you try to be helpful to them even if you think their questions are stupid, you'll spend far less time writing defensive comments on HN, and far more time watching adoption for your library grow, which I assume is something you may want.
Best of luck!
asyncio is an asynchronous I/O framework shipping with the Python Standard Library. In this blog post, we introduce uvloop: a full, drop-in replacement for the asyncio event loop. uvloop is written in Cython and built on top of libuv.
uvloop makes asyncio fast. In fact, it is at least 2x faster than nodejs, gevent, as well as any other Python asynchronous framework. The performance of uvloop-based asyncio is close to that of Go programs."
The question asked was if there is "anything [similar in] python", so there's an obvious requirement of being able to use it from python. That leaves either something with a bit of a friendly python wrapper, or just calling out directly to (only) pure C/C++ code. The latter might be even faster, but at that point it's questionable if calling it from python really is worth the trouble at all.
So, I think it's fair to say that "uvloop may be 'something [similar in]' python".
I'm guessing that the scaffolding code for the websocket-part in python when working with uvloop might indeed give a meaningful performance and/or memory hit (I'm leaning towards memory probably being the most significant difference here).
I'd be interesting to compare a python+uvloop websocket implementation and uWS (both using nodejs and c++) -- and at some point see if wrapping uWS for python would make a meaningful difference.
You need to realize, that libuv itself was simply too heavyweight for this project. Think about that statement for a while.
This is why I use UNIX syscalls directly, and only use uv_poll_t, not the full-on uv_tcp_t. This is the level of optimizations we are talking about -> when libuv is considered too heavyweight...
When libuv becomes too heavyweight to keep up, having this discussion about how a Python async network library could implement similar performance is just purely ridiculous.
WARNING -> NO OFFENCE