Hacker News new | past | comments | ask | show | jobs | submit login
PyPy3 (Python 3 support) 2.1 beta 1 released (morepypy.blogspot.com)
123 points by pjenvey on July 30, 2013 | hide | past | favorite | 15 comments



Just tried it on a program I had lying around and PyPy3 2.1b1 took about 37 times the time that PyPy 2.0.2 takes to run it. So, yeah, some performance regressions, but it's still great news that Python 3 support is here!


Ouch. I'd submit the program to them to test.


This is so great! Thank you guys for all the hard work you're doing.

Couple of questions: does it have support for JITed continuations as python2 pypy branch? How long will it take to add 'yield from' support from 3.3?


All of the stackless/continuation related features included in Python 2 pypy should be supported on PyPy3 or it's a bug.

Implementing Python 3.3's yield from in RPython should actually be fairly easy. One of the PyPy GSoC students may get around to doing it this summer


Has the build process for PyPy been simplified any? Is it more thoroughly documented now?

Attempting to port it to a new platform seemed an exercise in futility. Every time the build failed and I had to go fix something, I had to start the build from the beginning again. I gave up after a few days.

Given that the build took a few hours on a high-end Xeon workstation with plenty of I/O and memory, I remain hesitant to attempt that again.


First, please stop spreading FUD. It does not take "a few hours", it takes ~30-40min. That's pretty bad, but not the end of the world.

Second, you don't "just" try to build it - there is an extensive test suite that should be made to pass before you even try building the thing. We're not completely crazy, we won't wait "a few hours" before every single change can be tested.

I know it kind of makes it "boring work" instead of "interesting ranting", but this is the reality.


I can't see an architecture doc, or other docs describing the build toolchain. Since pypy doesn't use commonly used build tools (or does it?) porting is going to be harder than something that uses a well know build toolchain like autotools/cmake/etc for example.

What would a high level porting strategy be? Get it running on CPython first, run tests..., set up platform specific details in files X,Y,Z, then try and translate? Perhaps the people who did the ARM port could write a short post on the strategy they took? What things can you disable to get a minimal pypy working first?

CPython has a short Porting document of which the style could be mostly copied and improved on with pypy specific details. https://github.com/python-git/python/blob/master/Misc/Portin...

I like the "Bang on it until you get a >>> prompt" :)


There is an architecture doc, but definitely there is no porting guide. I would start with sending a mail to pypy-dev or asking on IRC, but generally "get the tests running first, all of them" is a good start.


I'm sorry, it is most certainly NOT "FUD".

I have an Intel(R) Xeon(R) CPU W3540 @ 2.93GHz workstation with two 500GB drives and 12GB of memory.

The last time I ran the build process, it took hours while PyPy drew pretty pictures on the screen in ascii:

https://twitter.com/erikjanss/status/112867649666564096

All I did was run the standard build target following the documentation provided.

My understanding is that while it's busy drawing pretty ascii art (which I have no problem with, by the way) it's building PyPy from the RPython source, which according to other users as recently as December of 2012 "takes ages":

https://groups.google.com/forum/#!msg/julia-dev/4TeGQh8wbmI/...

Hence why I asked if this had been improved yet.

I'm not trolling, or spreading FUD. I'm asking if a significantly negative experience I had has been improved.


>First, please stop spreading FUD

One person's subjective opinion of the time taken (which could even be objective, if it takes > 1 hour on HIS system), even exaggerated != FUD.

The term FUD is about an INTENTED, SMEAR campaign. Let's leave it to the era of the MS-Wars, where it belongs.


What are you referring to by 'new platform'? ARM?


A currently unsupported OS platform on AMD64; one that Python supports, but PyPy does not.


I believe that is only the case for Windows, since there are pretty much no PyPy devs on Windows.

Don't build it yourself, it's a useless pain in the ass.


PyPy doesn't yet run on some of the UNIX variants that Python supports.


finally py3. great job!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: