The only design decision that prevents it from compiling the standard library is the lack of C support. The solution is to reimplement those modules in Go or Python. Anything else that doesn't compile is due to bugs in this alpha implementation (as far as I can tell, anyway).
Right, this comment was about compiling the standard library, not building a GIL-less Python.
EDIT: From what I understand, supporting C extensions and threadsafe garbage collection are the two biggest challenges to removing the GIL. This project uses Go's threadsafe garbage collector, so the latter shouldn't be a problem.
It doesn't need GIL, because it offers subset of functionality that python has. It is not even capable of compiling all python standard library.
This code is for Google to move away from python. They can include python libraries in their go code and then one by one rewrite it in go.
weberc2 4 points · Jan 2017
The only design decision that prevents it from compiling the standard library is the lack of C support. The solution is to reimplement those modules in Go or Python. Anything else that doesn't compile is due to bugs in this alpha implementation (as far as I can tell, anyway).
[deleted] 2 points · Jan 2017
PyPy also doesn't natively support C extension and also needs GIL. C support is one of reason of GIL's existence but not the only one.
weberc2 1 points · Jan 2017
Right, this comment was about compiling the standard library, not building a GIL-less Python.
EDIT: From what I understand, supporting C extensions and threadsafe garbage collection are the two biggest challenges to removing the GIL. This project uses Go's threadsafe garbage collector, so the latter shouldn't be a problem.
EDIT2: This page has some good information: https://wiki.python.org/moin/GlobalInterpreterLock