Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "what is the core of Python programming language". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Why do you ask this question?

It's no secret that we need a Python implementation for WebAssembly. It not only introduces Python into browsers, but also introduces Python to mobile because both iOS and Android support running JavaScript as part of the application. All this excites me.

But when I thought of creating a new Python to accomplish the daunting task, my brain began to ask the question: what on earth is Python? We have lived with CPython for so long that I suspect that most of us simply think of "Python = = CPython". PyPy tries to be compatible in order to implement the implementation details of CPython. Basically, most of the Python implementations I know try to pass CPython's test suite and be as compatible with CPython as possible.

This is daunting. Python implemented by CPython is very dynamic and exposes a lot of things that make sense only when implementing Python using an interpreter. For example, PyPy has a baseline interpreter for JIT, but there are many things that can be used in Python to force PyPy to turn off JIT and stick to bytecode. REPL alone can make things very dynamic, because the interpreter immediately dynamically parses, compiles, and executes everything that enters REPL.

It made me wonder what on earth Python is. What is the core of the language? What baselines do all Python implementations need to cover to truly describe themselves as Python implementations that people can still recognize? Or from my point of view, how much does a person need to implement to compile Python to WebAssembly directly and is still considered a Python implementation?

Does Python need REPL?

What really got me thinking about this was when I started thinking about how to compile Python into WebAssembly? Another interpreter is not implemented, but actually emits static WebAssembly from the Python source code and is still reasonably called "Python".

One thing I know is that dynamic compilation through eval () or compile () may not be easy because WebAssembly's security model validates the module at load time. This means that there is no structure for running arbitrary code in the memory space of other code, which can make the implementation of REPL tricky.

But it makes me wonder: does Python really need REPL? Don't get me wrong, it's very convenient, but if an implementation doesn't have REPL, is it no longer Python? I think the Python that doesn't answer is still Python, it just lacks a (potentially key) feature.

This got me thinking about what parts of Python need to be considered "Python"?

Can you live without locals? It is a very dynamic thing that can arbitrarily collect all defined local variables and their values into a dictionary. If you are in an intepreter like CPython, you only need to get some local variables from the current execution framework. But in compiled languages, this requires more work, because you must know when to collect all this information, because it is not necessarily ubiquitous when local () is called.

Or how about people rewriting local () itself? In CPython, this is not a big deal, because the builtins module has a _ _ dict__, that you can override, and it will simply propagate to any future calls. But in compiled languages, this kind of detection takes more effort, and such a check will eventually degrade performance.

What about sys.settrace ()? It actually triggers a callback for each bytecode, and if the code is compiled, it won't work properly. You can forge it by checking to see if a trace function is set after each line, but this seems a bit excessive when you don't set such a hook most of the time (though, it may be a compiler flag compiled with this support).

What about sys._getframe ()? The compiled language does not have to access the execution framework directly, so do you need to bother to simulate it? Because execution frames can be requested by any function, you need to be ready to provide execution frames on demand.

As you can see, there are a lot of things in Python that make it difficult to compile (Nuitka is therefore in a better position to take up the challenge). But I bet you won't use the things I mentioned above 99.9% of the time, so if an implementation doesn't use them, can it still be considered "Python"?

How much compatibility is useful?

I don't have a good answer to this question. But its answer shows the difficulty of implementing Python and its compatibility with existing software. What I want to say is that I don't think WebAssembly needs to support a lot of Python software to work. WebAssembly has access to other language ecosystems, such as Rust and JavaScript, so the chances of doing what you need in other languages are definitely greater than zero.

I don't have an answer.

It might make sense to develop a compiler that converts Python code directly to WebAssembly and sacrifices some compatibility to improve performance. It may make sense to develop an interpreter that targets the design of WebAssembly while maintaining compatibility with existing code. In their WebAssembly efforts, it may make sense to simply support RustPython. Maybe Pyodide can help us get there. I don't think these possibilities are all wrong in nature, it may only boil down to the one that arouses enough interest to see that it is useful to others.

That's all for "what's the Core of the Python programming language?" Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.