PyPy support for Python 3 (pypy-dev)(mail.python.org)
mail.python.org
PyPy support for Python 3 (pypy-dev)
http://mail.python.org/pipermail/pypy-dev/2011-September/008288.html
5 comments
Warms my heart to read a solid confirmation that PyPy as a project is committed to implementing Python 3 support. For some time now I've been lamenting the dilemma that is having to choose between PyPy and CPython 3.x, plus it's always left a bit of a bitter after-taste that any rise in the popularity of PyPy would serve to prolong the transition pains as long as there wasn't a clear and public plan toward Python 3 support.
Additional discussion on reddit:
http://www.reddit.com/r/Python/comments/kd38b/pypys_python_3...
There's discussion of the Python version supported by AppEngine in there ... it's funny to think that once PyPy supports Python 3, and assuming the RPython interpreter implementing that support will still be compatible with Python 2.x, you might actually be able to use Python 3 on AppEngine by running PyPy's Python 3 interpreter against whatever Python 2.x AppEngine offers.
In fact, has anyone tried running PyPy's 2.7 interpreter on AppEngine's 2.5?
Not that I would expect such a setup to be production-ready, but just for the fun of it ...
In fact, has anyone tried running PyPy's 2.7 interpreter on AppEngine's 2.5?
Not that I would expect such a setup to be production-ready, but just for the fun of it ...
What are the builtin and third-party libraries that people have had trouble with when using PyPy (modulo having to configure an appication to use PyPy at runtime instead of CPython)? For web-dev, scientific or otherwise?
In particular, are there any such problem cases where there is insufficient documentation?
In particular, are there any such problem cases where there is insufficient documentation?
Cython is the biggest issue right now with PyPy: lots of 3rd party libraries depend on it, lxml and pyzmq come to mind.
I can't wait for Cython support: in our tests PyPy delivers amazing RAM savings, PyPy seems to have a particularly efficient list implementation specialized for small strings: we're seeing x3 savings there, in addition to 20% speedup.
I can't wait for Cython support: in our tests PyPy delivers amazing RAM savings, PyPy seems to have a particularly efficient list implementation specialized for small strings: we're seeing x3 savings there, in addition to 20% speedup.
If Cython compiles to standard c modules, and pypy claims to support standard c modules in its latest release, doesn't pypy now support Cython? (In the same way that Cpython does?)
PyPy's support for the C API is highly limited and not something to be relied upon for new code. IIRC the Cython plan is for Cython to grow the ability to emit pure Python with ctypes.
PyPy doesn't have a specialized list for small strings. It might land one in the near future, your findings are a bit weird, but objects might be smaller because of smaller GC headers.
Cheers, fijal
Cheers, fijal
What is with the estimated costs? Are they looking for corporate sponsors? I've never seen a FOSS project do such a thing when discussing future plans.
they don't expect the work to be done solely by volunteers, and are going to ask for donations on their website. it's laid out in the first paragraphs:
The task is huge and it's unlikely that it will be
completed shortly based only on volunteer work, so we
came up with the following proposal, which splits the
work into several steps and sub-steps, togheter with an
estimate of how much money is needed to complete each
one.I really wish Google would support PyPy. It'd be such a small amount of money for them to fund development. Given the PyPy team's demonstrable success and Google's otherwise strong commitment to Python I can't understand why they don't.
That Unladden Swallow seems to have died a quiet death in the end sure doesn't support the idea that Google is easy to truely commit to such efforts, though.
My impression is that's because it was a failure technically, not because Google didn't support its goals.
I thought the story was that the Unladden Swallow team had actually started expanding into new directions after walking away from LLVM disappointed, but the project then got cancelled from higher-up?
I guess my point, in keeping with the parent, is that you'd expect Google to be interested in sustaining a team looking into performance improvements in an important part of their runtime longer-term, but that didn't happen.
Edit: On an unrelated note, it's good fun to take a look at http://speed.pypy.org/ and consider how close the averaged 4.5x speedup of PyPy trunk over CPython is to the original "make it five times faster" goal of Unladden Swallow.
I guess my point, in keeping with the parent, is that you'd expect Google to be interested in sustaining a team looking into performance improvements in an important part of their runtime longer-term, but that didn't happen.
Edit: On an unrelated note, it's good fun to take a look at http://speed.pypy.org/ and consider how close the averaged 4.5x speedup of PyPy trunk over CPython is to the original "make it five times faster" goal of Unladden Swallow.
There's a retrospective here which addresses quite a lot of it: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...
Partly it sounds like performance-critical code at Google tends to get written in a lower level language instead, so Python performance isn't as critical, even though they use it quite a bit.
Agree that it'd be great if they helped out the PyPy team though, since it's showing such great promise and has some pretty impressive numbers already.
Partly it sounds like performance-critical code at Google tends to get written in a lower level language instead, so Python performance isn't as critical, even though they use it quite a bit.
Agree that it'd be great if they helped out the PyPy team though, since it's showing such great promise and has some pretty impressive numbers already.
They are invested in Go and Dart.
Actual donation page:
http://pypy.org/py3donate.html
http://pypy.org/py3donate.html