Thus is x very hard problem— bug people are trying. https://www.pypy.org/posts/2018/09/inside-cpyext-why-emulating-cpython-c-8083064623681286567.html
-CHB On Sun, Apr 23, 2023 at 5:39 AM Jelle Zijlstra <jelle.zijls...@gmail.com> wrote: > At the Language Summit a few days ago we discussed this problem. I wasn't > involved in this discussion, but it's a hard one to solve. > > You may be interested in HPy (https://hpyproject.org/), which aims to > provide what you are looking for. > > El dom, 23 abr 2023 a las 6:18, Evan Greenup via Python-ideas (< > python-ideas@python.org>) escribió: > >> Dear All >> >> Python is a "glue" language, its dynamic nature has programming advantage >> and performance disadvantage. >> The best way to use Python is write Python code for high-level stuff and >> use native programming language like C, Rust, Zig, V for low level stuff. >> Currently, there is library like PyO3 and so on. >> However there is a lot of limitation in those library. >> >> 1. The "FFI" library is implementation specific. For example, PyO3, >> it highly depend on specific version of CPython. If you use a different >> version of CPython, there is some work for you to do. If you don't use >> CPython, for example use another Python Implementation, This framework may >> not work. >> 2. The project structure is rigid. When using something like PyO3. >> you must make your project structure following certain pattern, then >> finally produce a complete wheel package. The majority Python programmer >> does not write a whole Python project for a installable package and pack >> it >> up then install it. They are edit Python source file iteratively and run >> it >> locally. >> 3. It is really ridiculous when you want to stick some item on the >> wall. You need to totally redesign this item and manufacture a new item to >> fit the glue you are going to use. As a glue language, Python should be >> designed to glue other native programming language as a feature of Python >> programming language itself not the tricks of certain variant of >> implementation. >> >> It would be nice to add the feature in Python Standards (no matter what >> implementation is used) to satisfy the following capabilities: >> >> - The interface is universal across all variant and version of Python >> implementation (There might be protocol version update and may not >> backward-compatible, but it is not bounded with Python implementation). >> The >> overall effect is in some extent like JSON, but it is not a structured >> string, It is a lively data structure with in-memory representation, they >> are unified no matter what Python variant is used and what low level >> native >> language is used. >> - This mechanism is transparent to users, there is modules in >> standard library to support it. If user want, they can design a toy native >> programming language, and use Python to write a compiler for it. Then >> write >> a module with custom language then compile and import it. This mechanism >> provide user with maximum flexibility. >> - almost zero-cost abstraction. Even if it not depend on CPython >> tricks. But the central idea of this mechanism is still the dynamic >> linking >> feature provided by operating system. The detailed format will be slightly >> different. It doesn't introduce new stuff in nature. It doesn't spawn new >> process, nor launch a VM, and nor I/O operations is involved. It just make >> some basic data representation conversion and invoke the method in dynamic >> library. >> >> This is just a raw idea. If it is valuable, it can take a discussion and >> make further steps. >> >> Thanks >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/R2NBDZHCCTJNRN27XP7PY7QLKDLYKSAW/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/WZKFVNEIZHZLTE4UPAHZ4F4SHT3JVNXN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K627B2X7WG773L4BP3JB7SJT5ABC3GXD/ Code of Conduct: http://python.org/psf/codeofconduct/
