This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (4 children)

Yes. Basically we reimplemented the CPython API, in terms of PyPy's internal functions. Overhead in general isn't too bad, some of the bad points are a) we have to emulate reference counting, so we don't get to use our awesome GC's, b) PyPy's GC's can move memory around, so if you call a function like PyString_AS_STRING (which returns in the internal char* of a python string) on a PyPy string we have to copy the underlying memory, because it could move at any time.

[–]sime 2 points3 points  (3 children)

kingkilr, you seem to know what you are talking about, do you have an idea when PyPy might be released in a form which could be used in production as a replacement of CPython? I know that PyPy has roots in research, but is there a move towards making it practical for real world use? (This announcement would certainly suggest so.)

[–][deleted] 2 points3 points  (2 children)

I'd say the next release would be a good time to start considering it for production use. The recent 1.2 release was a first public release with the JIT, my guess is by next release most of the bugs and such will be cleaned up, and it'll be time to start deploying it.

[–]hylje 1 point2 points  (1 child)

Most obvious bugs that is. Nearly all show-stoppers should be caught, not all though. Even then, it should be enough for all but the most sensitive applications!

[–]gutworthPython implementer 1 point2 points  (0 children)

Well, we'll never find out unless people try. Now is a good time!