Mejor respuesta
Python es interpretado. Aunque convierte la fuente legible por humanos a código de bytes, que almacena en el archivo .pyc, y el archivo .pyc es portátil, el archivo .pyc se interpreta sin embargo. Por ejemplo, algunos intérpretes de Python almacenan en caché objetos singleton para enteros de uso común -100 a 100. Algunos no lo hacen. ¿Qué importancia tiene?
Un sistema puede interpretar legalmente la operación is, que compara Object.id () como Verdadero o Falso.
x = 20
x is 20 # Both True and False are valid results.
Demostración:
$ python3
Python 3.6.3 (default, Oct 3 2017, 21:45:48)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 30
>>> x is 30
True
>>> x = 23442.2
>>> x is 23442.2
False
>>>
Conversión de Python desde la fuente al bytecode lleva tiempo, razonablemente es más rápido para Python leer el archivo .pyc que leer la fuente y reconstruir el .pyc.
Hubo un tiempo y no he estado al día con importar módulos, cuando python buscaría \_\_init\_\_.py en un directorio para cargar un módulo. Fue prudente mantener ese archivo \_\_init\_\_.py pequeño, para que en su mayoría simplemente importara de manera secundaria el código útil que residiría en un archivo .pyc.
¿Y la optimización de Python fue a alguna parte? La última vez que supe, que fue hace bastante tiempo, el .pyo era un .pyc sin comentarios.
Respuesta
He respondido esto antes aquí: la respuesta de Quildreen Motta a ¿Se puede compilar un lenguaje de alto nivel como Python haciéndolo tan rápido como C?
Pero, en resumen, la gente no usa C o C ++ porque «re rápido , los usan porque tienen un rendimiento predecible . Un programador puede entonces tomarse el tiempo para optimizar manualmente sus programas y es mucho más fácil razonar sobre el rendimiento resultante de esas optimizaciones.
Eso no es tan fácil de hacer en un lenguaje dinámico, como Python. No obstante, PyPy le dará más rápido que Rendimiento de C (gcc, no totalmente optimizado a mano) en varios escenarios, simplemente no puede predecir cuándo sucederán esos escenarios porque depende de varios factores (qué datos pasan por su programa, qué ramas se han tomado, la estabilidad del ramas sobre t ime, hotness del código, etc).
Por supuesto, PyPy hace todas las optimizaciones mientras ejecuta su programa, por lo que necesita hacer una gran ponderación de costos y algunas optimizaciones no se aplican por eso. Al igual que los compiladores de AOT podrían pasar 3 meses analizando su código para generar CÓDIGO REALMENTE RÁPIDO, los optimizadores JIT podrían pasar minutos analizando su código. En ninguno de los casos, es probable que el costo valga la pena, por lo que no hacen eso.
Hacer compiladores AOT para Python es mucho más difícil, porque Python es un lenguaje dinámico. Compiladores AOT, como shedskin: un compilador experimental (de Python restringido) a C ++ , usa un subconjunto restringido de Python para poder analizarlo estáticamente. Este enfoque es similar al uno tomado por RPython, en el que se basa PyPy.