With Pyjion on the way from MS and the Python core devs declaring if it works they'll make the API changes[0] to connect CPython3 to an external JIT like Pyjion changes the game.
The window is closing to declare PyPy the successor to CPython2 before Python3 finds a way to steal the thunder and more people migrate from Python to new languages like Go or Python3.
PyPy is a fantastic piece of technology that should take the forsaken mantle of Python2 for itself. Just needs a few political moves. PyPy is pure technological innovation. Python3 is pure technological churn and pure politics.
You guys deserve the money and fame that will come with being the successor to Python2. Do it and good luck!
I disagree. First, Python 2 is actually good. I see this sentiment a lot: because there is 2 and 3 people have a hard time figuring out which one to use. I am hoping that in 2016 we'll finally have full support for Python 3 in all major libraries.
Python 3 is a pleasure to use. It's a strict upgrade over Python 2, fixing some long standing warts. I needed to happen, and it is backwards incompatible because it fixes some fundamental flaws. I don't care about the Python3 politics and technological churn, because at its core it's a language that just works.
Now, I don't know where PyPy fits with all of this. I haven't had an opportunity to use it for anything. Or rather, Python 2 has not failed me in such a way as to require me to go seeking PyPy. But I am glad for its existence, because once it is usable for the general purpose case, I look forward to not having to deal with the GIL, and having somewhat better concurrency model.
> The window is closing to declare PyPy the successor to CPython2
PyPy is much more than Python + JIT. It's a whole framework for writing interpreters in Python, with the bonus that any interpreter you build gets an awesome JIT for free. I whipped up a brainfuck interpreter in a few lines of RPython, and bam I have a compiled executable that JIT compiles my brainfuck on the fly.
You can build interpreters for Ruby, PHP, whatever language you want. There is no window running out for that and that's the best bit of PyPy. The fact the flagship implementation for this framework is a Python interpreter is cool but not the only or coolest bit about the project - it's so much more.
That being said, the primary devs of PyPy/RPython are also a consultancy group, from what I recall, and PyPy is one of the tools they use for their consulting
i'm not privy to the details but this is a recent development and i too hope it ends up successful. i remember in the past they were granted quite a lot of EU research money which, as can be seen, has been spent quite well :)
> migrate from Python to new languages like [...] Python3
> PyPy is pure technological innovation. Python3 is pure technological churn and pure politics.
I'm not sure why you're pointing fingers about being political when you're the person introducing the politics. I don't know why you're positioning python3 as an entirely different language—this discounts hundreds of thousands (millions?) of hours the python community has put into ensuring one of the smoothest transitions between incompatible language versions. This is also not mutually exclusive with projects like PyPy (which has python3 compatibility, I might add) and pyjion.
Sometimes fragmenting languages, as python did with 2 and 3, is necessary. It always sucks. I don't think your entirely negative and substance-less beef with python3 is adding anything to the conversation about PyPy's c api changes.
Is this the remaining major hurdle toward getting mega-libraries like SciPy, pandas, and BioPython to work? Or will the C API in PyPy always be less performant than CPython?
If more people start using PyPy for ad-hoc data analysis, it could help nudge it out of its niche into the mainstream.
Yes, the remaining part is a hurdle, but hopefully not a very big one. The interface will always be slower, but hopefully you won't have to interact with it much (you almost never do with scipy). We have a cunning plan on how to make the numpy interface faster though, stay tuned [To recap: generic-cpython-extension-border-crossing will always be slower, btu maybe we can do hacks for numpy]
