13 comments

[ 3223 ms ] story [ 92.1 ms ] thread
Interesting! Seems like a hyper-framework, a one-fits-all solution for a python backend. I would like to see any benchmarks comparing this to tornado/twisted/nodejs and perhaps an async mongoDB client implementation. Great work anyway!
Thinking about new tech in term of performance is silly. If you need performance NOW just stick with the known solution because odds are you also need stability and a well tested platform.
No, it's not. It's a good indicatior of how performant the framework is likely to be in the future, in the context of ballparks.

For example, if this version already is as quick as comparable software written in C, you know that chances are that it will be even faster in the future and not slower. If it uses an hour to open a port and send a package, that doesn't bode well for future development.

1) Are known solutions always performant (which is a broad topic)?

2) "I would like to see any benchmarks comparing this to..." != "I only care about performance and nothing else matters"

Finally a concurrency framework that works with Python 3! I will definitely have to check this out, because Twisted is the only thing preventing me from switching (and Gevent doesn't support it either).
What about concurrent.futures from standard library?
It's not really a concurrency framework, just some tooling. It does absolutely nothing to provide evented-IO for example.
The porting process is slow but sure, fortunately. Some parts already work. It'd be cool if we stopped hitting broken stdlib functions. (Turns out that sometimes regular quotes did actually mean bytestrings.)