The point of this technology is generality. It is theoretically possible, given enough work, run Python directly in Wasm. The effort would be, though, Python specific and you would need to start from scratch for every single language.
CheerpX allows running unmodified X86 programs, it does not matter if it's Python or something else. It does not even have to be a REPL, for that matter. We use this tech in production to run the legacy Flash plugin, for example: https://leaningtech.com/cheerpx-for-flash/
That's via emscripten. I suspect by "directly" they meant something like Python bytecode -> WASM. Which I think might be possible later, when some of the proposals[1] like GC, exceptions, etc, are done. That sort of fuzzy line where WASM is somewhat like ASM, and somewhat like a language VM.
There have been several ports of Python to JS or to wasm over the years. Pyodide is the most mature today, but another interesting one is pypy.js which ported PyPy and even included a JIT!
But I agree that CheerpX allows running more things. There will always be a use case for "just run an x86 binary" when you don't have the source code. But for things where the source is available a proper port to wasm like Pyodide will be faster.
As pointed out by another user, I was actually referring to compiling Python _directly_ to Wasm. Porting the C++ _implementation_ to Wasm is obviously possible.
Well, Pyodide does port CPython directly to wasm. You're basically running CPython on wasm instead of on x86 - it's just another architecture. That's the natural thing to do I think.
But I see what you're saying, one could also theoretically write a new implementation of the Python language that uses wasm in a more "direct" way. We are exploring exactly that right now using wasm GC, compiling Java and Dart objects directly to wasm GC objects and so forth. That approach still has a lot left to prove, and it may not make sense for all languages, and specifically, I'm not sure if Python would benefit from it at all. So that is very much unclear.
In practice, when you want to run Python on wasm today, I think Pyodide's approach of porting CPython to wasm is the natural way, and it works well. That's what I was getting at.
actual_cpu(browser_sandbox(wasm(x86_emulator(python_interpret(python source)))))
Is there some way to do a more direct JIT in wasm? Or maybe just a normal python interpreter written in wasm? Or would that not be faster?