[rudi-c]

That's not how progress happens in practice. First of all, it's not a known fact that a Python JIT implementation with reasonable maintenance cost, functionality, and performance can exist. Pyston is trying to prove that it is possible, but it's not exactly a weekend project.

Even if you solved all the political issues around getting CPython maintainers to accept performance contributions (discussed already in this thread), adding a JIT to the main CPython codebase would surely slow the pace of development of other Python features. If the effort were to fail, then CPython's primary maintainers will have wasted a whole bunch of time coordinating with the JIT effort. I'm personally rooting for Pyston to succeed but it's admittedly an ambitious project.

So forking off an experiment is the right move here. Pyston's existence as a side-project is pulling no resources away from the main project -- but it would if it was trying to send changes upstream.

Hypothetically the Pyston developers could be making non-JIT contributions to CPython instead, but developers aren't interchangeable commodities. Pyston's engineers have expertise in optimizations -- they may not be as skilled or interested in language development.