[quantumhobbit]

I really want pypy to be the future of Python along with python3. I haven't used it in a while but the performance improvements I could get by switching from python somecode.py to pypy somecode.py were magical.

So what is the best way I can help support pypy3? Are there any easy issues I can help contribute to?

[ronjouch]

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."

[dr_zoidberg]

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

[rcthompson]

Just to note, the new compact dicts in Python 3.6 are apparently based on the PyPy dict implementation: https://docs.python.org/3.6/whatsnew/3.6.html#other-language...

[raymondh]

More properly, both the CPython 3.6 and PyPy compact dicts are based on this proposal: https://mail.python.org/pipermail/python-dev/2012-December/1... and this proof of concept: http://code.activestate.com/recipes/578375

[wyldfire]

> My biggest issue with PyPy is library/modules incompatibility.

Addressing this has been a big focus for PyPy lately. You should consider re-evaluating PyPy. numpy (arguably one of the heaviest users of C extensions) works on pypy at very nearly 100% of its tests passing.

[dr_zoidberg]

We tested last week, distorm3 and yara bindings for python are the big things that just didn't work (yet again) with our test case (the volatility memory forensics framework). We got them installed with pip, but they just didn work. Volatility still runs without them, it just complains a bit.

Also, startup time of volatility exploded for no apparent reason (4 seconds CPython vs 12 seconds PyPy, latest 2.7 branch). Real analysis time was indeed faster (~30 seconds CPython vs ~15 seconds PyPy), but half the plugins won't work.

Plus, in the end (startup+analysis), both CPython and PyPy got close results (though arguably PyPy was some about 15% faster).

[wyldfire]

Might be worth reporting since you have a reproducible failure and a use case for which the performance is not satisfactory. You can tune some of the JIT behavior with command line options -- that might make it kick in sooner and you might see a net benefit.

[sho_hn]

Original numpy? Or their private reimplementation started because the original won't run ...?

[wyldfire]

The former.

See http://pypy.org/download.html#numpy-via-cpyext