As someone who was at the pycon au sprints watching this come together and hearing Russell talk about the potential uses that motivated him, I'm excited to see this continue. I'm hoping to find a little time to try and work on it in the coming week.
Pypy.js has demonstrated Python JavaScrip interoperability and DOM integration, so there's no reason this project can't have similar features. We can ship useful chunks of server side Python to the browser and stop duplicating our efforts.
Another way to do this would be to use numba package to generate LLVM IR from Python bytecode (it supports a rich set of instructions including numpy stuff, has type inference, etc), and then run it in the browser via emscripten, with some adjustments to the IR if required.
And most general-purpose Python (e.g. dicts, most builtins, etc...) require running in "object mode" which is not standalone, it calls into the CPython API and thus requires an underlying CPython runtime.
So no, numba is not an other way to do that. shedskin[0] might be though.
> wouldn't it make more sense to target WebAssembly?
I don't think it would. A Python source -> WebAssembly bytecode compiler needs updates with every enhancement to the Python language.
An engine for running Python bytecode in the browser only needs updates with change to Python bytecode, which is presumably more stable than the language -- all the language-side work can be shared with the mainline CPython implementation.
The goal is being able to pickle something like a Django template and then run it client side. It's based on past work that has shown its possible to build bytecode interpreters without much code. It's not as much about targets and cross compilation or anything like coffeescript. It's about trying to run existing Python bytecode with as little code as possible.
Does that make sense? It's not like there's a bunch of Python bytecode sitting around that we can't possibly re-compile. It makes a ton of sense to create a Python-to-WebAssembly compiler, but very little sense to spend time adding functionality to a browser that's specific to Python bytecode.
Web browsers have become a de facto universal operating system, and JavaScript its instruction set. Unfortunately, running other languages in the browser is not generally possible. Translation to JavaScript is not enough because browsers are a hostile environment for other languages. Previous approaches are either non-portable or require extensive modifications for programs to work in a browser.
This paper presents Doppio, a JavaScript-based runtime system that makes it possible to run unaltered applications written in general-purpose languages directly inside the browser. Doppio provides a wide range of runtime services, including a file system that enables local and external (cloud-based) storage, an unmanaged heap, sockets, blocking I/O, and multiple threads. We demonstrate Doppio's usefulness with two case studies: we extend Emscripten with DOPPIO, letting it run an unmodified C++ application in the browser with full functionality, and present DoppioJVM, an interpreter that runs unmodified JVM programs directly in the browser. While substantially slower than a native JVM (between 24× and 42× slower on CPU-intensive benchmarks in Google Chrome), DoppioJVM makes it feasible to directly reuse existing, non compute-intensive code.
Pypy.js has demonstrated Python JavaScrip interoperability and DOM integration, so there's no reason this project can't have similar features. We can ship useful chunks of server side Python to the browser and stop duplicating our efforts.