What Defines a True Python Implementation? REPL, Compatibility, and WebAssembly

Why ask this question?

We need a Python implementation for WebAssembly, which is no longer a secret. It brings Python to browsers and, because iOS and Android support JavaScript as part of apps, also to mobile devices, which is exciting.

However, when considering the daunting task of creating a new Python implementation, I ask: what exactly is Python? Having lived with CPython for so long, many of us simply equate “Python” with CPython. Projects like PyPy aim for compatibility by reproducing CPython’s implementation details, and most implementations strive to pass CPython’s test suite and be as compatible as possible.

This is daunting. CPython’s Python is highly dynamic and exposes many features that only make sense in an interpreter implementation. For example, PyPy has a baseline interpreter for JIT, but Python code can force PyPy to disable JIT and stick to bytecode. The REPL makes things especially dynamic, as the interpreter instantly parses, compiles, and executes everything entered.

This makes me wonder what Python truly is, what the core of the language is, and what baseline features every Python implementation must cover to still be recognizable as Python. From my perspective, how much must be implemented to compile Python directly to WebAssembly and still be considered a Python implementation?

Does Python need a REPL?

What really sparked this question was thinking about compiling Python to WebAssembly without building another interpreter, but instead emitting static WebAssembly from Python source while still reasonably calling it “Python”.

I know that dynamic compilation via eval() or compile() is hard because WebAssembly’s security model validates modules at load time, meaning there’s no structure to run arbitrary code in another module’s memory space, making REPL implementation tricky.

But this leads me to ask: does Python truly need a REPL? Not to misunderstand—REPL is convenient, but if an implementation lacks it, is it still Python? I think a non‑interactive Python is still Python; it just lacks a potentially key feature.

Which parts of Python must be present to be considered “Python”?

Can you live without locals()? It’s a very dynamic feature that can collect all defined local variables and their values into a dictionary. In an interpreter like CPython you can fetch locals from the current frame, but in a compiled language you must know when to collect this information because calling locals() doesn’t guarantee the data is readily available.

Or what about overriding locals() itself? In CPython this isn’t hard because the builtins module provides a dict that you can replace, and it propagates to future calls. In a compiled language, detecting and handling this requires extra effort and can hurt performance.

What about sys.settrace()? It triggers a callback for every bytecode, which can’t work if the code is compiled. You could fake it by checking for a trace function after each line, but that seems excessive unless the compiler supports it via a flag.

And sys._getframe()? Compiled languages don’t necessarily have direct access to execution frames, so you’d need to simulate it if you want to provide frames on demand.

As you can see, many Python features make compilation difficult (Nuitka is thus well‑suited for the challenge). Yet I bet most of the mentioned features are rarely used, so if an implementation omits them, can it still be called “Python”?

How much compatibility is useful?

I have no definitive answer, but it illustrates the difficulty of implementing Python and its compatibility with existing software. I think WebAssembly doesn’t need to support the entire Python ecosystem to be useful; it can interoperate with other ecosystems like Rust and JavaScript, making it feasible to implement only the necessary parts.

I have no answer

Developing a compiler that translates Python code directly to WebAssembly, sacrificing some compatibility for performance, may make sense. Likewise, an interpreter designed for WebAssembly that retains compatibility with existing code could be valuable. Supporting RustPython in their WebAssembly efforts, or leveraging Pyodide, might also be viable paths. I don’t think any of these options are inherently wrong; the right one will emerge based on interest and usefulness.

Original link: https://developer.51cto.com/art/202008/622721.htm Author: Machine Learning and Data Analysis