Live data from Hacker News

First Python 2.7 interpreter to use multiple cores

mail.python.org

41–42 of 42 posts

Re: First Python 2.7 interpreter to use multiple cores

#41
post #32
post #26

This is incredibly interesting, and the people working on it are incredibly smart. But I think it's a slight oversell to call this a python 2.7 interpreter. For instance, most scientific computing code that runs in cpython 2.7 won't run on pypy. It's impressive from a computer science point of view. But, pypy has a ways to go before I'd call it a python interpreter without adding qualifications.

PyPy is officially sanctioned as python 2.7 interpreter. Cannot run scientific code does not rule it out. This is more a problem on the scientific code being too implementation specific (for good reasons though). This is known to be a problem to a lot of people (including me), however it does not rule pypy as a python 2.7 interpreter (without qualifications).

My apologies. I mistakenly lumped C extensions in as an inherent part of python. I was wrong.

Re: First Python 2.7 interpreter to use multiple cores

#42
post #15

Earlier quoted context omitted.

I will get excited when it actually works out to be faster than interpreters with the GIL. I'm a bit disappointed that Python seems to have no interest in standardizing a lightweight-thread (greenlet, coroutine) interface that isn't an awful mess. yield is powerful but coroutine implementations with it are baroque and opaque. Java-style threading has a million gotchas and the interface is just a dog. I want to be abl…

Which of the existing coroutine implementations have you tried, and what did you dislike about it?

The issue isn't that all the third-party implementations are no good, several are good. It's that there is no Pythonic one which is also standard and blessed, which would help with interoperability as well as providing one obvious way to do it.

I'd rather Python moved in the direction of go than Java

Post reply on HN