The author appears to not be aware of where the big leagues are. Additionally, as is becoming a recurring theme here, he doesn't know about PyPy nor Twisted. This is continually disappointing.
If you think twisted is a solution to the problems mentioned in the OP, you haven't understood the problem. Twisted may be a solution to IO bound processes, where you do cooperative parallelism instead of preemptive (aka threads). It is utterly useless for CPU bound processes (e.g.: you want to compute some expensive operation on top of a big numpy array, twisted does not help you with that at all).
He may know about PyPy, but need to use libraries that only work with CPython. Numpy is an example of this type of library, though there are many others.
Unfortunately, PyPy isn't a viable alternative for most scientific computing problems...
- There wasn't up to date documentation about basic topics, like how to compile it.
- There isn't comprehensive documentation about what RPython is supposed to be.
- In the repository, it's hard to figure out what is RPython and what isn't, what's code for the interpreter, what's code for the stdlib, etc. Specially because modules import from each other in crazy ways.
- It's hard for someone who's not a contributor to peek at the code to figure out why client code isn't running on PyPy, since the only people who understand the architecture are the authors.
- The code itself is pretty opaque and light on comments.
I understand it's a fast moving project and that it had major rewrites so far, but those are the reasons why I say it's not a viable alternative for production.
>The author appears to not be aware of where the big leagues are. Additionally, as is becoming a recurring theme here, he doesn't know about PyPy nor Twisted. This is continually disappointing.
Do you even know the author? I'm pretty fucking sure he does know about PyPy and Twisted. He is a HN regular, a good tech blogger, and he has TONS of experience with Python for production use.