> Right now, PyPy is probable the biggest reason why many users don't migrate to Python 3 yet

I've met hundreds of pythonistas, in all sorts of different places. A lot of them wanted to migrate to Python 3.X not a single one told me that PyPy was a reason.

I fall in that camp too. I worked on a project where i really wanted to migrate to Python 3, mostly to have a saner Unicode story, but couldn't do it because it was deployed on Google App Engine :(

You may already know, but you can use 3.4 if you switch from the "Standard Environment" to the "Flexible Environment".

https://cloud.google.com/appengine/docs/flexible/

Yep. Already tried that, but i found too many disadvantages on the "flexible" environment (still in beta, bad documentation, much slower deploys, minimum of one instance always running, etc) that i preferred to stay out of that for the time being.

Similarly, Python 3.5 is (for me and probably others) the biggest reason for not using PyPy

Agreed. Looking forward to the 3.5 port.

You mean you don't use 3.5 be cause pypy does not support it.

No, it seems like they are in the same position as myself.

They (and myself) are not using PyPy because PyPy does not support Python 3.5

> brings Python's speed to NodeJS level

Does anyone have a benchmark? I hear this claim a lot, but I haven't seen NodeJS being that much faster.

The Techempower benchmarks show them each having their strengths, with 3 'wins' apiece:

https://www.techempower.com/benchmarks/#section=data-r12&hw=...

The usual Techempower caveats apply: I have no idea about the implementations or any possible constraints on these, YMMV.

Thank you, that seems useful. I must be reading it wrong, though, because I see wsgi completing three times more responses than node.js, which seems wrong. I also can't find the "three wins each" that you reference.

EDIT: Ah, I just noticed the different benchmark tabs at the top, thanks.

NodeJS/V8 is faster than CPython for obvious reasons - V8 is JIT compiled while CPython is not. PyPy closes the gap.

LuaJIT made the news for having an interpreter that beat V8’s JIT a while ago. There are a lot of traits about languages and their implementations that makes looking at their compiler features a poor way of determining speed.

> Right now, PyPy is probable the biggest reason why many users don't migrate to Python 3 yet.

Does PyPy have that many users?

Doesn't seem that way to me.

For actual real world apps with a lot of IO, your PyPy benefit is kinda small.

For actual number crunching, I guess. Which is the whole scientific side of Python.

Python is weird that it is 50% webapp hipsters ala Ruby, and 50% scientists in lab coats sitting in the lab crunching.

Well, PyPy does not actually help much with raw number crunching -- a scientist will use numpy for native matrix math, or numba to JIT a tight loop that can't be writted in numpy easily. PyPy really helps in the in-between cases: a few weeks ago I had to write a script to pull a few million rows from a database, process them nontrivially, and dump them to a file. What do I use here? CPython and Ruby will take days. Perl will probably take days, unless I am just doing text processing which perl is optimized for. I can write C or C++, and have the headache of debugging memory errors in a script that will only run once. Or, I can write PyPy and have immensely convenient syntax that will run reasonably quickly (Luajit also occupies this space for me).

Well if this task is trivial to parallelize.. I would spin up 100 GCE machines for 1 penny each per hour after today's price drop (combined total of $1 per hour for 100 CPUs of action).. and pull those few million files and dump to a cloud drive in 1 hour flat.

It's a tricky sweet spot PyPy has. Certain tasks that need CPU power but not too much CPU power and you want to spend time to make it run in parallel but not too much time to make it run across many machines.

(By no means am I a PyPy or CPython expert. Just toyed with them and want to understand the bounds...)

But now you have to manage that deployment which is also nontrivial.

Depends on your setup I guess? I have a a GCE cluster setup where I can:

1) Point a metadata variable at my git repo

2) Spin up 100 GCEs

3) Each will pip install requirements.txt from the git checkout

4) Each will read a metadata to get the command and run it. (Could hardcode run.py or something).

Realize not everyone has this sitting around, but you can do it in an afternoon. Then gives you instant Python supercomputer for anything you want across many projects.

The setup for that sounds significantly nontrivial, although interesting.

Scientific Python benefits more from (properly) vectorized numpy code, Cython, Numba and Numexpr than what it gains from PyPy.

From my experience, one of the biggest issues with PyPy is that it's not a magic pill you take and suddenly all your Python code runs faster -- that's how they "sell" it. But in many cases, the idiomatic code for CPython results in slow PyPy execution, and idiomatic PyPy code results in slow(er) CPython execution.

That means that you have to refactor your code, and whereas you won't be breaking compatibility with CPython, your CPython performance will (most often) suffer. So, unless you're the sole user of your code, or you have control or decision power over most of your users, (or you just don't care to keep good CPython performance) your project might not benefit: "yeah, in PyPy it runs 2x faster, but 80% of our clients use CPython and are complaining over a 5x slow down -- ditch that code and get back to the previous version" may end up being the feedback from someone above you in hierarchy.

> Python is weird that it is 50% webapp hipsters ala Ruby, and 50% scientists in lab coats sitting in the lab crunching.

Don't forget about the ops guys using it for automation!

Oh yes my ansible brothers and their lack of Python3 support ;)

Where brothers == inbred cousins

Hahaha kinda.. but if Ansible brothers are inbred cousins, Puppet and Chef brothers are certified insane asylum.

Well, it weights in favor of Python 2, and considering that until recently the incencitives for Python 3 were still light... It's not really about having users, but having the possibility of switching from CPython to PyPy if you face performance issues.

PyPy is still not really a performance option for numerical computing.

Are you not satisfied with NumPy and associated tools?

Very satisfied, and that is why I can't really switch to PyPy

I wonder if uvloop will work with such pypy. The speed would be awesome!

It's a possibility. uvloop is written in Cython so it will depend on whether PyPy3 supports what uvloop uses through Cython: http://docs.cython.org/en/latest/src/userguide/pypy.html

We'll find a way. Worst case it's possible to rewrite it using cffi.