How can it be the future if Py 3 support is the side project?

I can't use PyPy until it implements a real Python 3 version, i.e. one that supports asyncio, which is the real future. Until then, I will just be reading about PyPy on Hacker News and just sighing...

Edit: For everything I use, I try to find an asyncio version - Slack client [0], SSH [1], etc.

[0]: https://github.com/gfreezy/slacker-asyncio/

[1]: https://github.com/ronf/asyncssh

I second the asyncio endorsement. I started using Python 3 just to try out asyncio and never went back. It works like a dream.

After they get momentum by attracting people with their speed improvements, it will be a lot easier to attract talent and money to tackle Python 3. The reason Python 3 is on the back burner is that there simply isn't a large enough audience right now. That could change if they keep increasing their reach.

>The reason Python 3 is on the back burner is that there simply isn't a large enough audience right now.

Funnily enough the reason I haven't adopted using PyPy is down to their lack of Python3 support. I think you're underestimating the amount of people using Python3.

Pip statistics tells us they're not that many.

Do you have any recent statistics?

I'm guessing that most people who use Python 3 are using recent versions of pip that have caching built in, so that may skew the results a bit.

From this (last year), Python 2.6 is bigger than 3:

https://caremad.io/2015/04/a-year-of-pypi-downloads/

>I'm guessing that most people who use Python 3 are using recent versions of pip that have caching built in, so that may skew the results a bit.

Since pip updates itself too, why wouldn't people using Python 2 also have newer versions?

I'm guessing a lot of people who are stuck on Python 2.6 are also stuck on old versions of pip.

I think he means not enough companies willing to sponsor python 3 support.

> After they get momentum by attracting people with their speed improvements, it will be a lot easier to attract talent and money to tackle Python 3

Well, this is a catch-22, because folks like me and my team won't touch it unless it's Python 3. We're not a Python shop, but have flirted with Python before. It wouldn't make sense for us to write new code in Python 2.

After they get momentum? But pypy has existed for a long time. They are in a maturity phase now, surely.

There are major bug fixes and compatibility and performance improvements in this release. They're also asking for a large amount of money to start a push to add Py 3 support. And NumPy support is still improving - they'll gain a lot of users as that becomes complete. None of this seems like "maturity phase", especially in terms of userbase or funding.

You don't get many cases of 20% memory consumption improvements in mature projects...

You should read through PostgreSQL release notes some day.

"20% consumption" is more a factor of how much memory you have installed and how much you intend to use than PyPy's maturity. I frequently use malloc()/mmap() to consume much more than 20% of system memory.

EDIT: strike this, I misunderstood.

I think they're talking about a 20% improvement in memory consumption release-over-release, not complaining that it's consuming 20% of their memory.

Py 3 is not the future of CPython either. Even today the overwhelming majority of projects use 2, even new projects.

While this has historically been the case, Python 3.4/3.5 has really sped up adoption of Python 3, and from an open source maintainer, Python 3 is making large inroads.

Also, libraries are slowly going to drop Python 2.x support and go Python 3 only.

>While this has historically been the case, Python 3.4/3.5 has really sped up adoption of Python 3, and from an open source maintainer, Python 3 is making large inroads.

If by great inroads you mean "around 6-10% in PyPI after 8 years of trying", then yes.

But unless it gets over 30-40% it's not anywhere near significant in my charts...

As soon as Python 2.7 was put in maintenance mode I see much more people talking about Python 3. There are even libraries that are Python 3 only.

All the developers needed was a kick in the butt. If only PSF did that sooner.

>The underlying basis for PyPy has big implications for a number of dynamic languages

Isn't it just a tracing JIT? Aren't these relatively well understood and implemented dozens of different ways?

The novelty is that the JIT is produced by compiling a simple interpreter.

http://morepypy.blogspot.com/2011/04/tutorial-writing-interp...

Others have shown up and take the same approach, Graal and Zippy for example.

I've never heard of those. Python on the other hand has been my primary professional language for years. i.e. people pay me to program in python.

See how PyPy might be a tinsy bit more relevant / meaningful to professional developers.

Java developers know them quite well. In fact Java 9 is getting a plugin API for Graal.

I still don't see the novelty.

Its a JIT compiler run-time. You put a program in the JIT-compiler's run-time. And it was JIT compiled. The program you gave it just so happens to have Turning Complete behavior. It doesn't change anything the JIT compiler is doing.

It's like a compiler boot-strapping itself. It seems really impressive, but really the program is just doing its job on an input. The input just happens to be itself.

> I still don't see the novelty.

Are you familiar of the state of the art in JIT compilers at the time PyPy's JIT was developed? It was absolutely a novel idea at the time, and was published as a novel result in a peer-reviewed paper. I'm not sure how else to convince you of that.

> However, applying an unmodified tracing JIT to a program that is itself a bytecode interpreter results in very limited or no speedup. In this paper we show how to guide tracing JIT compilers to greatly improve the speed of bytecode interpreters. One crucial point is to unroll the bytecode dispatch loop, based on two kinds of hints provided by the implementer of the bytecode interpreter.

> Applying a trace-based optimizer to an interpreter and adding hints to help the tracer produce better results has been tried before in the context of the DynamoRIO project [27], which has been a great inspiration for our work. They achieve the same unrolling of the interpreter loop so that the unrolled version corresponds to the loops in the user pro- gram. However the approach is greatly hindered by the fact that they trace on the machine code level and thus have no high-level information available about the interpreter. This makes it necessary to add quite a large number of hints, be- cause at the assembler level it is not really visible anymore that e.g., a bytecode string is immutable. Also more ad- vanced optimizations like allocation removal would not be possible with that approach.

http://dl.acm.org/citation.cfm?id=1565827

Did you actually look at the blog post? The novelty is the idea that you generate a JIT compiler from the interpreter using a few hints. Truffle does that, but Truffle is newer than PyPy.

It's not about novelty, it's about realization. PyPy exists and works as both an open source project and as a codebase, which is no easier to achieve than coming up with an idea. That said, PyPy has yet to demonstrate real impact outside the Python community, and projects with a somewhat similar aim to what's being discussed (the Parrot VM) have likewise not gotten to significant uptake. We'll see. PyPy is definitely already useful at other things, though.

> PyPy exists and works as both an open source project and as a codebase, which is no easier to achieve than coming up with an idea.

I have no idea what you are getting at here.

The post I was replying to was misunderstanding "this is new!" as "this is the first time this exists!" when it's more about "this is the first time this is available!", where availability is complex and defined by factors like governance, distribution, quality, accessibility, infrastructure, communication ... these are the things that tend to be make or break long after novelty had its moment.

Whether "this is the first time this is available!" is true or not is open to debate (it depends in part on how you weigh the listed concerns), but parent's post didn't read on it.

So you just adding a user program to a REPL/Parser and cramming it into a JIT?

You can do this in Javascript, or LLVM-IR just as easily.

The main blessing is also its biggest curse. You are writing a language to move fast, and change often. Its a good learning tool, but a constantly changing language is next to impossible to build value upon.