In addition to code/doc contributions, you can donate: http://pypy.org/py3donate.html

The page mentions pypy3's current status as of August 2016: "We are soon releasing a beta supporting Python 3.3. For the next full year, though, see PyPy gets funding from Mozilla for Python 3.5 support. Individual donations through here are still welcome, and go towards the same goal, which is upgrading PyPy to support Python 3.x (which really means 3.3/3.5 by now). Thanks to all our past contributors! Your money has been put to good use so far."

I don't want PyPy to be the future of Python. Python 3.5 (asyncio, os.scandir, functools part of stdlib, to name a few) was a big step in the right direction for those of us still locked in Python 2 so we can say to our bosses "hey, look all the good things we're missing". Python 3.6 with compact dicts working ~4x faster than old dicts[0, 1] is also huge for that -- plus, since dicts are used all over the place in Python this may have a global impact on all Python performance (don't quote me on that, but it's a possible side-effect).

My biggest issue with PyPy is library/modules incompatibility. I work in forensics, and I honestly tried using most of the python based tools with PyPy, and many just don't work because of lib/module dependencies. The few that do, may or may not run faster, depending on your use case and even the case (some have slower initialization but process faster, so with a big enough target file you get things done quicker). And while I am sort of a developer, I also have to solve cases, so I don't have enough time to sit and port all the libraries of 20 different tools to work in PyPy.

And if performance is still a need (it always is in forensics, with more cases with larger drives/memory coming all the time), there's Cython, and with it we've gotten speedups ranging from the few percent (about 14% from "removing the interpreter") to 20-30x faster -- which has the side-effect of revealing yet another bottleneck in the application, but hey, now you know.

So, seeing the things that are coming to Python 3, I sincerely hope PyPy exists and goes on living, but I much rather CPython be the future of Python -- because it is good, compatible (mostly), it has the right tools, and things work.

[0] https://mail.python.org/pipermail/python-dev/2016-September/...

[1] https://twitter.com/raymondh/status/776322068723798016

I'm secretly hoping that f-strings make it into pypy 3.5... it's just a teensy little bit of syntax, right? Right...?

PyPy uses a JIT (just-in-time) compiler, as opposed to the static interpreter of CPython (the default/canonical implementation of Python from python.org). What this means is that the PyPy interpreter uses runtime information about your program to compile your Python code into very efficient machine code on the fly. Because this compilation is done at runtime, PyPy has lots of data about things like variable types, how often each function gets called, etc, and it can use that data to generate really fast code in many cases.

PyPy is a completely different implementation of Python, so it's impossible to simply contribute improvements from it to CPython. To answer the question I think you're asking, though, the main reason we can't just have PyPy replace CPython as the default implementation isn't strictly technical: The Python community (Guido in particular) has decided to keep the reference implementation (CPython) as simple and consistent as possible, so that it's easy to contribute to and doesn't have any surprising behavior. PyPy, by comparison, is an incredibly complex piece of software. Even if you ignore the fact that it would make contributions harder, its performance is, in many scenarios, actually significantly worse than CPython's, because its optimizations rely on specific patterns within your code. I think it's mostly a good thing that PyPy is its own project and not the default implementation of Python, because it allows Python (the language) to grow much faster than it would otherwise.

I hope that answers your question. I apologize to anyone who knows more about the details than I do if I over-simplified things. :)

PyPy is a different implementation of a python interpreter, it includes a JIT to rewrite hot code into assembler. See www.pypy.org for more info. The JIT cannot be tacked on to CPython (what you call python3) since it is part of the interpreter.

If its server-side performance you are interested in you might also be interested in uvloop, which brings node's event loop library to async python with impressive results https://magic.io/blog/uvloop-blazing-fast-python-networking/

Personally while I appreciate what PyPy are trying to do, for a lot of real world use cases you can get really impressive performance out of python using the right libraries (see: the entire Python scientific computing stack).

Add Julia to the list, since it's directly competing with Python on scientific computing, and the other two aren't really that much (maybe Go a little).

There won't be breaking changes from 3.3->3.5, so the code changes are the same either way. I guess skipping a release saves the effort of making the release/prioritizing things that appeared in 3.4.