¿Por qué no hay otros lenguajes de programación que compilan en código de bytes Python?

En Java, hay varios lenguajes que se compilan en código de bytes de Java y pueden ejecutarse en la JVM: Clojure, Groovy y Scala son los principales que recuerdo de mi cabeza.

Sin embargo, Python también se convierte en bytecode (archivos .pyc) antes de ser ejecutado por el intérprete de Python. Puede que solo sea ignorante, pero ¿por qué no hay otros lenguajes de programación que se compilen en python bytecode?

¿Es solo porque nadie se molestó o hay algún tipo de restricción o barrera inherente que dificulta hacerlo?

Simple: la última vez que lo comprobé, Python no tenía una especificación formal, incluido su código de bytes. CPython es la especificación, y no se requiere portabilidad de código de bytes IIRC. Por lo tanto, es un objetivo móvil e indocumentado diseñado para un lenguaje específico.

Existen múltiples lenguajes JVM porque había personas con talento que querían escribir código que funcionara con el código Java existente, pero no querían escribir Java .

Aparentemente, no hay programadores que quieran trabajar con el código Python existente, pero odian a Python lo suficiente como para portar otro idioma al intérprete de código de bytes de Python.

Puede ver esto de dos maneras: hay lenguajes alternativos para la JVM porque Java está muy extendido, o no hay lenguajes alternativos para el intérprete de código de bytes de Python porque Python no es una mierda.

Hay deficiencias técnicas como el GIL en CPython, pero pocas deficiencias percibidas en el lenguaje , por lo que el tiempo de ejecución no es el punto de venta de la comunidad de Python. Exactamente lo contrario, hay más opciones de tiempo de ejecución de back-end debido a la insatisfacción con la implementación de GIL / CPython.

El lenguaje Java es mucho más difamado que el JVM (incluso en la comunidad Java).

La JVM está bastante bien considerada en la mayoría de los círculos; por lo tanto, el deseo de un lenguaje frontal diferente / mejor con los beneficios de la JVM back-end altamente optimizada.

Yo digo que Mason Wheeler tiene razón. Es principalmente un problema con el Global Interpreter Lock que hace que la concurrencia sea un problema muy espinoso. Dado que hay otras máquinas virtuales que hacen concurrencia realmente muy bien comparativamente, tiene sentido desarrollar lenguajes para ellos. También Python ha tenido un cambio importante de idioma recientemente y muchas de las bibliotecas no se han puesto al día haciendo que la compatibilidad sea una pesadilla leve a veces. Por ejemplo, porque uso PIL para el trabajo de visión, tengo que codificar en Python 2.7 o inferior. Este no es el caso con las configuraciones JVM o CLI que, en particular en el caso de este último, se diseñaron teniendo en cuenta la interoperabilidad del lenguaje.

Investigé un poco más y aparentemente hay dos GIL, no solo uno. El otro controla las importaciones .

Las otras respuestas tienen mucho sentido, pero en realidad ahora hay lenguajes que se compilan en Python. Donde hay voluntad ...

No sé nada acerca de estos lenguajes, pero parecen funcionar al transpilar su código fuente a Python AST y dejar que Python compile los árboles para codificar en bytes, evitando los problemas mencionados en otras respuestas.

Según los comentarios, actualmente conocemos tres lenguajes alternativos que usan Python VM (siéntase libre de agregar otros aquí):

• Mochi se describe a sí mismo como un lenguaje de programación de tipo dinámico para la programación funcional y la programación estilo actor .
• Hy : se describe a sí mismo como un dialecto de Lisp que está incrustado en Python .
• dg : se describe a sí mismo como un lenguaje (técnicamente) simple que se compila en el bytecode de CPython .

Otra razón es que la JVM es un ecosistema altamente optimizado, bien desarrollado y extremadamente completo. Por sí solo, compite extremadamente bien con cualquiera de los otros lenguajes compilados. (No diré que es la mejor máquina virtual de propósito general que existe, pero ciertamente he apostado mi carrera en eso). Por lo tanto, obtener acceso a la JVM, sin escribir código de bytes, es deseable en sí mismo.

Sin embargo, la máquina virtual Python es buena, pero (nada en contra de Python) tiene algunas deficiencias serias. El entorno de tiempo de ejecución de Python se adapta bien a la naturaleza dinámica del lenguaje, pero realmente puede sorprenderlo cuando se familiarice con su uso de memoria, bloqueo global o modelo de subprocesos.

En las comparaciones directas, la JVM suele ser dos veces más rápida que la máquina virtual Python. La JVM (sorprendentemente) incluso compite bien con el código compilado de forma nativa, basado en las optimizaciones "activas" que realiza. Y eso sin contar el manejo de hilos más sofisticado, etc.

Me encanta Python, de verdad, y odio decirlo, pero a veces el rendimiento simplemente me golpea los dientes; de lo contrario, ¿por qué las bibliotecas críticas de Python como numpy o scipy tienen que volver a caer en el código C?

En otras palabras, las personas que gravitan hacia Python lo hacen porque les gusta el lenguaje . Pero si desea escribir un nuevo idioma que se adapte a sus preferencias, es mucho mejor compilar en la JVM, porque su nuevo lenguaje idiosincrásico comenzará en uno de los mejores entornos operativos (subjetivamente, tal vez el mejor) disponible.