Pourquoi n'y a-t-il pas d'autres langages de programmation qui compilent en bytecode Python?

51

En Java, il existe plusieurs langages qui compilent en bytecode Java et peuvent s'exécuter sur la machine virtuelle Java - Clojure, Groovy et Scala étant les principaux dont je me souviens le mieux.

Cependant, Python se transforme également en bytecode (fichiers .pyc) avant d’être exécuté par l’interpréteur Python. Je ne suis peut-être qu'ignorant, mais pourquoi n'y a-t-il pas d'autres langages de programmation compilant le bytecode python?

Est-ce simplement parce que personne ne s'en occupe, ou existe-t-il une sorte de restriction ou d'obstacle inhérent qui rend la tâche si difficile?

python virtual-machine virtual-machine-languages

— Michael0x2a
source

30

... parce qu'ils ne veulent pas traiter avec le GIL? ;)

— Mason Wheeler

4

Les instincts me diraient que cela a beaucoup à voir avec la maturité de la machine virtuelle, bien spécifiée, et que la machine virtuelle est sur pratiquement toutes les plateformes ou stupide, facile à acquérir.

— Rig

4

Je soupçonne également que la plupart des machines virtuelles sont beaucoup plus rapides que les interpréteurs de python.

— Peter Smith

19

En ciblant le bytecode Java, vous obtenez toutes les fonctionnalités d'une machine virtuelle (sécurité, performances, portabilité, évolutivité, etc.). Cibler le bytecode Python ne vous rapporte pas beaucoup.

— David Schwartz,

3

Le bytecode Python n'est pas reconnu par les versions ultérieures de l'interpréteur Python. Comment peut-on implémenter un langage de programmation compilé en bytecode Python?

— Gus

77

Simple - la dernière fois que j'ai vérifié, Python n'avait aucune spécification formelle, y compris son bytecode. CPython est la spécification, et la portabilité du bytecode n'est pas IIRC. Il s’agit donc d’une cible mobile et non documentée conçue pour une langue spécifique.

— PL
source

22

En fait, les détails du format de code intermédiaire changent souvent entre les versions mineures, et même PyPy compatible à 99% n'essaie même pas (en fait, ils ajoutent leurs propres instructions de code secondaire).

Remarque: Python - le langage - a une spécification formelle (voir "PEP"). La 'machine virtuelle Python' n'a pas. Ceci est en effet différent de (par exemple) Java, où les deux sont spécifiés.

— Albert

56

Il existe plusieurs langages JVM, car certains talents voulaient écrire du code compatible avec le code Java existant, mais ils ne voulaient pas écrire Java .

Apparemment, aucun programmeur ne souhaite utiliser le code Python existant, mais déteste suffisamment Python pour porter un autre langage sur l’interpréteur de codes octets Python.

Vous pouvez voir cela de deux manières: il existe des langages alternatifs pour la machine virtuelle Java car Java est très répandu, ou il n'y a pas de langages alternatifs pour l'interpréteur de bytecodes Python car Python ne craint pas.

— Kevin Cline
source

7

J'espère que vous n'insinuez pas que Java est nul ou que Java est plus mauvais que Python :-)

— Giorgio

8

@Giorgio: Je veux dire que les créateurs de Groovy, Scala, Clojure, etc. pensaient qu'il y avait encore beaucoup à faire. Voulez-vous dire que Python est nul?

— Kevin Cline

8

Après avoir travaillé avec Python, je dirais que "faible facteur de succion" serait inexact. Cela fait beaucoup trop de choses communément acceptées et ce «soi» est extrêmement contre-productif. En fait stupide. Comment une méthode de classe ne sait-elle pas à quoi elle appartient?

— Rig

6

@Rig Personnellement, je pense que l'approche de Python est plus élégante. OO découle organiquement de la syntaxe plutôt que de demander un mot clé spécial qui ressemble à une variable. Pour expliquer pourquoi les méthodes de classe ne savent pas où elles se trouvent, c'est parce que les définitions de classe Python ne sont que du code et que ce code n'est pas privé de droits, car il se trouve qu'il se trouve dans une définition de classe. Vous pouvez définir des méthodes n'importe où et les ajouter à une classe au moment de l'exécution. En fait, vous pouvez utiliser la même fonction et l’utiliser comme méthode dans plusieurs classes, ce qui ne fonctionnerait pas vraiment avec le thisparadigme.

— Antimoine

6

Je pense que c'est une question de machines virtuelles et non de langues. La machine virtuelle Java est une machine virtuelle performante avec un récupérateur de mémoire de génération, JIT, etc. Tandis que CPython utilise le comptage de références et est un interpréteur. C'est CPython qui craint comme une plate-forme. Btw hyhy existe.

— PuercoPop

26

Il y a des problèmes techniques, tels que le GIL dans CPython, mais peu de problèmes de langage perçus . Le temps d'exécution n'est donc pas le point de vente de la communauté Python. Exactement le contraire, il y a plus d'options d'exécution en arrière-plan en raison du mécontentement avec l'implémentation GIL / CPython.

Le langage Java est beaucoup plus décrié que la JVM (même dans la communauté Java).

La JVM est plutôt bien considérée dans la plupart des milieux; par conséquent, le désir de disposer de fronts de langage différents / de meilleure qualité se termine par les avantages de la machine virtuelle Java hautement optimisée.

10

Je dis que Mason Wheeler a raison. C'est principalement un problème avec le verrou d'interprète global, qui rend la question de la concurrence d'accès très épineuse. Etant donné qu’il existe d’autres machines virtuelles qui effectuent des accès simultanés vraiment très bien, il est logique de développer des langages pour ces ordinateurs. De plus, Python a récemment changé de langue et beaucoup de bibliothèques n’ont pas réussi à faire de la compatibilité un cauchemar par moments. Par exemple, parce que j'utilise PIL pour le travail sur la vision, je dois coder en Python 2.7 ou inférieur. Ce n'est pas le cas avec les configurations JVM ou CLI qui, en particulier dans ce dernier cas, ont été conçues en tenant compte de l'interopérabilité des langues.

A fait quelques recherches supplémentaires et apparemment, il y a en fait deux GIL, pas seulement celui-là. L'autre contrôle les importations .

— Ingénieur du monde
source

1

"GIL free" est l'une des raisons techniques mentionnées dans "Raisons pour lesquelles les programmeurs CPython pourraient être intéressés par IronPython" dans le wiki Python .

— Yannis

1

@YannisRizos: L'accès au framework .NET n'est sûrement pas totalement sans conséquence. Bien sûr, il est possible que les utilisateurs de CPython se désintéressent totalement de cela.

— Robert Harvey

@RobertHarvey Ninja a édité cela. Bien que je ne pense pas à "l'accès à de nouveaux jouets de fantaisie" comme une raison technique (non que les jouets ne soient pas géniaux), le wiki mentionne également qu'IronPython est plus facile à étendre.

— Yannis

8

Les autres réponses ont beaucoup de sens, mais il existe actuellement des langages qui compilent vers Python. Où il y a une volonté...

Je ne connais rien à ces langages, mais ils semblent fonctionner en transmettant leur code source aux Python AST et en laissant Python compiler les arbres en bytecode, en évitant les problèmes mentionnés dans d'autres réponses.

Sur la base des commentaires, nous connaissons actuellement trois langages alternatifs utilisant la machine virtuelle Python (n'hésitez pas à en ajouter d'autres ici):

Mochi se décrit comme un langage de programmation à typage dynamique pour la programmation fonctionnelle et la programmation de style acteur .
Hy : Se décrit comme un dialecte de Lisp intégré dans Python .
dg : Se décrit comme un langage (techniquement) simple qui compile en bytecode CPython .

— Carl Smith
source

2

Il convient également de mentionner HyLang

— ideasman42

1

Et dg .

— hakatashi

6

Une autre raison est que la machine virtuelle Java est un écosystème hautement complet, hautement optimisé et bien développé. En soi, il rivalise extrêmement bien avec tous les autres langages compilés. (Je ne dirai pas que c'est la meilleure machine virtuelle polyvalente du marché, mais j'ai certainement misé ma carrière sur cela.) Donc, avoir accès à la JVM, à moins d'écrire en bytecode, est souhaitable en soi.

Cependant, la machine virtuelle Python est bonne, mais (rien contre Python) a de sérieux inconvénients. L'environnement d'exécution Python convient bien à la nature dynamique du langage, mais peut vous surprendre lorsque vous vous familiarisez avec son utilisation de la mémoire, son verrouillage global ou son modèle de thread.

Dans les comparaisons tête à tête, la machine virtuelle Java est généralement deux fois plus rapide que la machine virtuelle Python. La JVM (étonnamment) rivalise même bien avec le code compilé en mode natif, basé sur les optimisations "à chaud" qu’elle réalise. Et cela ne compte même pas la manipulation de fil plus sophistiquée, etc.

J'adore Python, vraiment, et je déteste le dire, mais parfois, la performance me donne un coup de pied - sinon, pourquoi les bibliothèques Python critiques telles que numpy ou scipy doivent-elles retomber dans le code C?

En d'autres termes, les personnes qui gravitent autour de Python le font parce qu'elles aiment le langage . Toutefois, si vous souhaitez écrire un nouveau langage adapté à vos préférences, vous ferez bien mieux de le compiler sur la JVM, car votre nouveau langage idiosyncratique démarrera dans l’un des meilleurs environnements d’exploitation disponibles (subjectivement, voire peut-être le meilleur).

— Rob
source