3 ms·

I could see this greatly benefitting python in particular. Compile cpython and all the dependencies against WASM/WASI, bundle WASM wheels, and wrap the whole th

by kortex 3y ago

I could see this greatly benefitting python in particular. Compile cpython and all the dependencies against WASM/WASI, bundle WASM wheels, and wrap the whole thing up in a single .wasm binary. Python portability woes are basically solved, provided your environment has the appropriate WASI runtime.

TekMol 3y ago
But my Python code does not run in a vacuum. It gets executed by Apache, writes to a file system, makes use of a gazillion of libraries and programs that come with Debian. What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack?
- kortex 3y ago
  Your python code is executed by Apache? You mean like WSGI? Well either way, the bytecode alliance is working on things like fork/exec. > What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack? Why does requests need a linux kernel? It's cross-platform. Strictly speaking it only needs the appropriate I/O calls. WASI provides a system interface to do I/O, network, files, etc. https://wasi.dev/ https://wasi.dev/ https://github.com/WebAssembly/wasi-sockets https://github.com/WebAssembly/wasi-sockets
mike_hearn 3y ago
Ironically this is solved already by the latest release of Graal, one of WASM's competitors: https://medium.com/graalvm/whats-new-in-graalvm-languages-161527df3d76With https://medium.com/graalvm/whats-new-in-graalvm-languages-16... You can now distribute Python applications or libraries as standalone binaries or JAR files without any external dependencies. The Truffle framework on which GraalPy is built, and the Sulong LLVM runtime that GraalPy leverages for managed execution of Python’s native extensions, enable virtualization of all filesystem access of Python applications, including those to the standard library and installed packages. So now you can build a standalone executable as follows: graalpy -m standalone binary - module my_script.py - output my_binary or a JAR file that runs on GraalVM and includes GraalPy as follows: graalpy -m standalone java - output-directory MyJavaApplication - module my_script.py The first form creates a fast starting native binary. The second is a portable bytecode standalone file. So this WASM dream is delivered already, just by a different group of people. Now, GraalPy is a different implementation to CPython so not all Python apps run on it yet. But obviously any WASMPy would have the same issue.
- kortex 3y ago
  Wow, that's pretty awesome! I don't know if WASMpy would be a completely different implementation, or just CPython compiled against a WASM target. Probably the latter. Which has already been done. https://github.com/jupyterlite/jupyterlite https://github.com/jupyterlite/jupyterlite
  - mike_hearn 3y ago
    Pyodide looks like an alternative implementation, at least in spirit.

by kortex 3y ago

TekMol 3y ago

But my Python code does not run in a vacuum. It gets executed by Apache, writes to a file system, makes use of a gazillion of libraries and programs that come with Debian. What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack?

kortex 3y ago
Your python code is executed by Apache? You mean like WSGI? Well either way, the bytecode alliance is working on things like fork/exec. > What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack? Why does requests need a linux kernel? It's cross-platform. Strictly speaking it only needs the appropriate I/O calls. WASI provides a system interface to do I/O, network, files, etc. https://wasi.dev/ https://wasi.dev/ https://github.com/WebAssembly/wasi-sockets https://github.com/WebAssembly/wasi-sockets

mike_hearn 3y ago

Ironically this is solved already by the latest release of Graal, one of WASM's competitors: https://medium.com/graalvm/whats-new-in-graalvm-languages-161527df3d76With https://medium.com/graalvm/whats-new-in-graalvm-languages-16... You can now distribute Python applications or libraries as standalone binaries or JAR files without any external dependencies. The Truffle framework on which GraalPy is built, and the Sulong LLVM runtime that GraalPy leverages for managed execution of Python’s native extensions, enable virtualization of all filesystem access of Python applications, including those to the standard library and installed packages. So now you can build a standalone executable as follows: graalpy -m standalone binary - module my_script.py - output my_binary or a JAR file that runs on GraalVM and includes GraalPy as follows: graalpy -m standalone java - output-directory MyJavaApplication - module my_script.py The first form creates a fast starting native binary. The second is a portable bytecode standalone file. So this WASM dream is delivered already, just by a different group of people. Now, GraalPy is a different implementation to CPython so not all Python apps run on it yet. But obviously any WASMPy would have the same issue.

kortex 3y ago
Wow, that's pretty awesome! I don't know if WASMpy would be a completely different implementation, or just CPython compiled against a WASM target. Probably the latter. Which has already been done. https://github.com/jupyterlite/jupyterlite https://github.com/jupyterlite/jupyterlite
- mike_hearn 3y ago
  Pyodide looks like an alternative implementation, at least in spirit.