Pourquoi Python a-t-il besoin à la fois d'un compilateur et d'un interprète?

Je peux comprendre le fait que Java a besoin à la fois d'un compilateur et d'un interprète. Il compile le code source en bytecode puis une machine virtuelle (sous Windows, Linux, Android, etc.) traduit ce bytecode en code machine pour l'architecture actuelle.

Mais pourquoi Python a-t-il besoin à la fois d'un compilateur et d'un interprète? Puisque Python n'est pas indépendant de la plateforme, pourquoi ne pas simplement utiliser l'interprétation? Pour autant que je sache, vous ne pouvez pas exécuter un programme Python (compilé en bytecode) sur une machine Windows ou Linux sans modification. Ou ai-je tort?

Pour autant que je sache, vous ne pouvez pas exécuter un programme Python (compilé en bytecode) sur chaque machine, comme Windows ou Linux sans modification.

Vous vous trompez. Le bytecode python est multiplateforme. Voir Est-ce que le bytecode python dépend de la version? Est-ce dépendant de la plateforme? sur Stack Overflow. Cependant, il n'est pas compatible entre les versions. Python 2.6 ne peut pas exécuter de fichiers Python 2.5. Donc, bien que multiplateforme, ce n'est généralement pas utile comme format de distribution.

Mais pourquoi Python a besoin à la fois d'un compilateur et d'un interprète?

La vitesse. L'interprétation stricte est lente. Pratiquement tous les langages "interprétés" compilent en fait le code source dans une sorte de représentation interne afin qu'il n'ait pas à analyser de façon répétée le code. Dans le cas de python, il enregistre cette représentation interne sur le disque afin qu'il puisse ignorer le processus d'analyse / de compilation la prochaine fois qu'il aura besoin du code.

Je peux comprendre le fait que Java a besoin à la fois d'un compilateur et d'un interprète.

Ce n'est pas le cas. Il n'y a rien dans la spécification du langage Java qui dit que Java doit avoir un compilateur. Il n'y a également rien dans la spécification du langage Java qui indique que Java doit avoir un interprète.

L'utilisation d'un interprète, d'un compilateur ou d'une combinaison des deux est entièrement laissée à la discrétion de l'implémentateur.

En fait, il existe des implémentations de Java qui compilent directement en code machine, par exemple le compilateur GNU pour Java gcj. Techniquement parlant, le compilateur Java Oracle OpenJDK compile également en code machine, en particulier en code octet JVM. Maintenant, vous pourriez dire, attendez une minute, ce n'est pas du code machine! Mais, il existe des interpréteurs logiciels pour le code machine x86, et il existe des processeurs matériels qui peuvent exécuter du code d'octet JVM, alors qu'est-ce qui rend l'un "natif" et l'autre non?

Notez que le code d'octet JVM se situe en dehors de la spécification du langage Java, tout comme le code machine x86.

puis une machine virtuelle (sous Windows, Linux, Android, etc.) traduit ce bytecode en code machine pour l'architecture actuelle.

Encore une fois, cela dépend uniquement de l'implémenteur.

La JVM Sun originale n'a jamais été traduite, elle a toujours été interprétée. Les interprétations JVM Oracle OpenJDK actuelles, et seules les parties souvent exécutées sont compilées. La machine virtuelle Maxine Research compile toujours JIT. L'implémentation Excelsior.JET se compile une fois à l'avance. La JVM IKVM.NET se compile en code octet CIL. Android Runtime se compile à l'avance, une fois, lors de l'installation. (De plus, Android Runtime ne comprend pas le code d'octet JVM, il utilise le code d'octet Dalvik, qui est un langage complètement différent.)

Mais pourquoi Python a-t-il besoin à la fois d'un compilateur et d'un interprète?

Encore une fois, ce n'est pas le cas. Il n'y a rien dans la spécification du langage Python qui dit que Python doit avoir un compilateur. Il n'y a également rien dans la spécification du langage Python qui dit que Python doit avoir un interpréteur.

Notez qu'en réalité, Python n'est jamais interprété. Toutes les implémentations Python existantes compilent toujours Python dans un langage différent. Ce langage peut alors ou non, à son tour, être interprété, mais ce langage est un langage différent de Python. Python n'est pas interprété.

pourquoi ne pas simplement utiliser l'interprétation?

Parce que Python n'est pas conçu pour être facilement interprété par les machines. Il est conçu pour être facilement interprété par l'homme. OTOH, le code d'octet CPython, est conçu pour être facilement interprété par les machines. Il est donc logique d' écrire du code dans un langage conçu pour les humains et d' interpréter dans un langage conçu pour les machines, et pour passer de l'un à l'autre, vous devez compiler.

Pour autant que je sache, vous ne pouvez pas exécuter un programme Python (compilé en bytecode) sur une machine Windows ou Linux sans modification.

Oui, vous pouvez. La machine virtuelle CPython est disponible pour Windows et Linux, tout comme PyPy, Jython et IronPython.

Les langues n'ont pas besoin d'être compilées ou interprétées. Les langues le sont . En fait, une langue peut parfaitement exister sans avoir d' interprète ou de compilateur! Par exemple, le Plankalkül de Konrad Zuse qu'il a conçu dans les années 1930 n'a jamais été mis en œuvre de son vivant. Vous pouvez toujours y écrire des programmes, vous pouvez analyser ces programmes, les raisonner, prouver leurs propriétés… vous ne pouvez tout simplement pas les exécuter. (Eh bien, en fait, même cela est faux: vous pouvez bien sûr les exécuter dans votre tête ou avec un stylo et du papier.)

Désormais, toute implémentation particulière d'un langage peut utiliser un compilateur (ou même plusieurs compilateurs), un interpréteur ou n'importe quelle combinaison. Mais c'est un trait de la mise en œuvre , pas du langage. Chaque langue peut être implémentée avec un compilateur, et chaque langue peut être implémentée avec un interprète.

Notez cependant que vous ne pouvez pas exécuter un programme sans interprète. Un compilateur traduit simplement un programme d'une langue à une autre. Mais c'est tout. Maintenant, vous avez le même programme, juste dans une langue différente. La seule façon d'obtenir réellement un résultat du programme est de l' interpréter . Parfois, le langage est un langage machine binaire extrêmement simple, et l'interpréteur est en fait codé en dur en silicone (et nous l'appelons un "CPU"), mais c'est toujours une interprétation.

Vous pourriez également être intéressé par ma réponse, qui explique les différences et les différents moyens de combiner les interprètes, les compilateurs JIT et les compilateurs AOT et cette réponse traitant des différences entre un compilateur AOT et un compilateur JIT .

Il est vrai que le bytecode ne convient pas comme format de distribution, mais cela ne signifie pas qu'il est inutile. En plus d'améliorer le temps de démarrage sur une machine donnée, après la première exécution, l'interprétation du bytecode est également beaucoup plus simple que l'interprétation d'un AST ou, Dieu nous en préserve, l'interprétation ligne par ligne.

Le bytecode est une représentation de bas niveau, plus régulière, plus compacte (à la fois sémantiquement et en termes de disposition de la mémoire) du code. L'ordre des opérations est déjà précisé, les noms des variables locales ont été résolus sous une forme plus simple (indices entiers). Aucune syntaxe compliquée à suivre, juste une instruction simple après l'autre. De plus, moins d'état est nécessaire: pour l'interprétation ligne par ligne, vous devez essentiellement garder un analyseur entier autour, et un interprète AST fait exploser la pile des appels avec sa traversée d'arborescence, tandis qu'un interprète bytecode a juste besoin d'une petite pile pour les valeurs temporaires et les locaux.

Ces facteurs et d'autres concourent à rendre les interprètes de bytecode beaucoup plus rapides que les autres interprètes.