Pyston is a fork of CPython and aims to maintain drop-in compatibility. PyPy is a completely separate implementation which is not fully compatible with CPython.
It's super-promising and actually looks pretty ergonomic in comparison, but it'll take rewrites of existing C API leveraging packages.
There's not really a way around that, since they have to interact with refcounting now vs a more abstract mechanism (eg. hpy's handles) that shield from the underlying GC mechanism.
My fear here is that this will be a cool project a few projects really looking for cross-interpreter python support leverage, but will otherwise be a non-issue.
It doesn't need to show performance improvement on PyPy or Pyston as much as <=0 performance degradation of CPython, which will stay everyone's primary target.
I guess when it shows to be mature, it'll just be a question for each library of whether the work is worth supporting alternative interpreters for their user-base or personal lives or job.
