Un interprète dans un interprète

Quelques mois de développement, j'ai décidé que mon étoile polaire pour Memphis serait d'exécuter un serveur Flask entièrement au sein de mon interprète. Je n'avais aucune idée de la quantité de travail que cela impliquerait, seulement que cela avait l'air cool et m'apprendrait probablement beaucoup de choses en cours de route. Si je me fixais cet objectif aujourd'hui, je choisirais peut-être FastAPI ou rien du tout parce que c'était idiot de ma part.

Python stdlib

Une décision importante que j'ai prise était de savoir comment gérer la bibliothèque standard Python. Comme vous le savez probablement, la bibliothèque standard d'un langage ne fait pas techniquement partie de la définition ou du runtime du langage. Il est inclus dans les versions afin de rendre le langage et le runtime plus utiles. Imaginez Python sans threading ni support asynchrone. Vous pourrez toujours évaluer des expressions et instancier des classes, mais la plupart des programmes prêts pour la production nécessitent une sorte de prise en charge de la concurrence.

Une option serait de réécrire moi-même l’intégralité de la bibliothèque standard. Je construis un interprète, n'est-ce pas ? Je pense que c'est l'approche adoptée par RustPython, qui est une voie admirable. Je pensais que j'avais assez de pain sur la planche pour faire fonctionner le temps d'exécution, je cherchais tous les coins à couper et j'ai décidé de ne pas le faire.

La bibliothèque standard Python se compose de deux parties principales : les parties implémentées en Python et les parties implémentées en C. Assez commodément, j'avais mon propre interpréteur Python. Puis-je simplement interpréter le fichier source Python de la machine hôte pour satisfaire le premier ? Oui, je pourrais. J'aurais besoin de prendre en charge toutes les syntaxes et fonctionnalités qu'ils utilisaient, mais après cela, cela fonctionnerait tout simplement.

C'est dans la partie C que ça devient intéressant. En 2023, j'ai pris la décision d'intégrer un interpréteur Python dans mon interpréteur Python sans bien comprendre ce que cela signifiait. Il était maintenant temps de réfléchir à cela et de décider si je voulais rester avec cette approche ou choisir une autre voie.

La boutique d'interopérabilité pour Rust et Python est Pyo3. En tant que seul jeu en ville, Pyo3 utilise l'interface de fonction étrangère (FFI) pour permettre à votre code Rust d'effectuer des appels dans le binaire CPython. Cela fonctionne en s'accordant sur l'Application Binary Interface (ABI), un concept que j'ai utilisé au cours de ma carrière chez AMD. Logiciel de base ftw !

Importer des modules

Mon cas d'utilisation initial était d'exécuter import sys et de lui demander un objet sur lequel je pourrais effectuer une opération d'accès aux membres. Je me lance ici dans le langage de l'interprète, mais c'est le type de session REPL dont je parle.

Python 3.12.5 (main, Aug  6 2024, 19:08:49) [Clang 15.0.0 (clang-1500.3.9.4)]
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys
<module 'sys' (built-in)>
>>> type(sys.modules)
<class 'dict'>

Obtenir cette fonctionnalité à l'aide de Pyo3 était simple.

pub struct CPythonModule(PyObject);

impl CPythonModule {
    pub fn new(name: &str) -> Self {
        pyo3::prepare_freethreaded_python();
        let pymodule = Python::with_gil(|py|
            PyModule::import(py, name).expect("Failed to import module").into()
        );

        Self(pymodule)
    }
}

Et nous pouvons utiliser cela pour piloter une session REPL similaire à Memphis, en supposant que vous vous souvenez du cocktail d'indicateurs de fonctionnalités pour que cela fonctionne.

Python 3.12.5 (main, Aug  6 2024, 19:08:49) [Clang 15.0.0 (clang-1500.3.9.4)]
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys
<module 'sys' (built-in)>
>>> type(sys.modules)
<class 'dict'>

Si vous vous demandez, ne pourriez-vous pas simplement utiliser cette approche pour importer l'intégralité de la bibliothèque standard (y compris les parties écrites en Python et C) et rendre votre vie entière, votre liberté et votre quête du bonheur plus faciles, la réponse est oui. Ce serait une approche valable ! Cependant, cela ferait de mon interprète davantage un shell autour de CPython que je ne le souhaiterais. Il s’agit d’un exercice d’apprentissage, donc je suis tout à fait favorable aux décisions arbitraires. Pour les puristes qui disent que charger n'importe quel morceau de CPython dans Memphis fait que Memphis n'est pas un véritable interprète, je dirais simplement : s'il vous plaît, montrez-moi votre interprète.

J'ai effectué un test rapide avec htop en exécutant import sys dans une session REPL en utilisant à la fois Memphis et CPython. À Memphis, comme cela chargeait les bibliothèques CPython en mémoire, cela augmentait l'utilisation de la RAM (Resident Set Size dans htop) d'environ 5 Mo. À titre de comparaison, le Memphis REPL après le chargement du module sys utilise environ 9 Mo de RAM, tandis que le Python REPL avant et après le chargement du module sys utilise à peu près la même chose. Je suis sûr que ce n’est pas une comparaison de pommes avec des pommes, mais cela m’a au moins dit que Memphis n’allait pas lentement étouffer mon ordinateur à mort.

Convertir des objets et devenir existentiel

La prochaine complexité de cette configuration consiste à convertir ma représentation d'objet Memphis en représentations CPython et vice versa. Il s'agit d'un travail en cours et ma directive principale était, au départ, de « ne pas échouer » et, plus récemment, de « afficher des avertissements lorsque vous effectuez une conversion avec perte ».

Voici ma conversion d'un PyObject, qui est la représentation d'objet du côté Pyo3, en un ExprResult, ma représentation Memphis.

pub struct CPythonModule(PyObject);

impl CPythonModule {
    pub fn new(name: &str) -> Self {
        pyo3::prepare_freethreaded_python();
        let pymodule = Python::with_gil(|py|
            PyModule::import(py, name).expect("Failed to import module").into()
        );

        Self(pymodule)
    }
}

Et voici la comparaison inverse. Notez que pour les deux, nous devons transmettre un objet Python, qui contrôle notre accès au CPython GIL (verrouillage global de l'interpréteur).

memphis 0.1.0 REPL (Type 'exit()' to quit)
>>> import sys
>>> sys
<module 'sys' (built-in)>
>>> type(sys.modules)
<class 'dict' (built-in)>

C’est un domaine riche que j’aimerais explorer davantage. Voici quelques-unes des orientations que j’ai envisagées :

1. Convertissez à chaque fois qu'un objet traverse l'interface FFI. (Et oui, je me rends compte que l'acronyme s'étend à l'interface d'interface de fonction étrangère.) C'est à peu près ce que je fais déjà, j'aurais juste besoin de le posséder et de ne pas me sentir comme un imposteur. Cela pourrait être simple mais inefficace.
2. Tenir un registre pour que chaque objet existe au plus une fois de chaque côté. Ce serait plus efficace que (1), mais cela nécessiterait une valeur stable que vous pourriez utiliser pour rechercher et relier ces objets.
3. Visez une représentation unique du côté de Rust et utilisez Pyo3 pour proxy et convertir paresseusement les champs selon vos besoins. Je pense que cela exploiterait toujours la fonctionnalité de (1), mais de manière plus efficace.
4. Faites correspondre la disposition de la mémoire d'un objet Memphis à celle d'un PyObject. Semblable à la façon dont #[repr(C)] fonctionne déjà dans Rust, cela serait similaire au rôle qu'un ABI joue pour un appel de fonction. Je ne suis même pas sûr que cela soit possible étant donné la différence entre ce que chaque partie doit faire pour son évaluation, mais cela m'intrigue.

Je prends de l'avance car je peux à peine charger un module C pour le moment, mais il n'y a vraiment aucune limite à ce que ma curiosité pourrait me mener dans ce domaine.

La fin

Je continue d'insister sur ce point lorsque j'ai rencontré un nouvel échec de conversion alors que je m'efforçais de faire démarrer Flask. Cet exercice est un bon rappel que tous les objets (ou classes, modules, etc.) sont un ensemble d'attributs qui existent dans un format connu en mémoire. Si nous comprenons suffisamment bien ce format, nous devrions être capables de faire des choses incroyables, que ce soit du côté de Memphis ou de CPython.

Cette philosophie guide également mon travail avec From Scratch Code. Si vous en avez assez de ne pas pouvoir faire fonctionner une bibliothèque dans votre code, je vous encourage à prendre du recul et à vous demander : que fait réellement la bibliothèque ? En avez-vous besoin ou une solution plus simple pourrait-elle fonctionner ? Je crois qu'il faut cultiver cette curiosité pour les logiciels et je serais heureux de vous aider à intégrer cet état d'esprit dans votre boîte à outils.

Si vous souhaitez recevoir plus de messages comme celui-ci directement dans votre boîte de réception, vous pouvez vous abonner ici !

Autre part

En plus d'encadrer des ingénieurs logiciels, j'écris également sur mon expérience en tant que personne autiste diagnostiquée chez l'adulte. Moins de code et le même nombre de blagues.

• Pourquoi ai-je soif de reconnaissance ? - Depuis l'organisation Scratch dot

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!