La nueva versión de Python reduce casi a la mitad el consumo de CPU: las implicaciones energéticas son enormes

Hace unos días, la cuenta oficial en Twitter de PyPI (Python Package Index), el repositorio de software vinculado al lenguaje Python, publicaba la siguiente imagen, mostrando el nivel de consumo de CPU resultante de la ejecución de Gunicorn (un servidor web basado en Python), justo antes y después de ser actualizado a la nueva versión de Python, la 3.11.

[#38 Desactivado]

#35 claro.

Una característica de Python es su capacidad de invocar código que está escrito en C. Eso es algo que también tienen Java, Rust, Go...

Cuando tú programas en Python e invocas una biblioteca intensiva en cálculo, por ejemplo Tensorflow para redes neuronales o Numpy para cálculo numérico, estas bibliotecas proveen una interfaz en Python para que puedas programar con ellas en Python, pero el núcleo (lo que hace los cálculos) está escrito en C/C++. De esta manera, por una parte ganas la comodidad de programar en Python (si es que te gusta ese tipo de lenguajes) y por otra parte consigues un uso eficiente de tus recursos y una velocidad de ejecución aceptable.

Por ejemplo, código NumPy que está escrito en C++: https://github.com/numpy/numpy/blob/main/numpy/core/src/npymath/ieee754.cpp
O código del núcleo de Tensorflow, también escrito en C++: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/ops/batch_ops.cc

C.c #30

[#44 Desactivado]

#38 #36 Gracias.

[#65 Desactivado]

#38 Exactamente, y precisamente es eso lo que lo hace tan interesante: sintaxis sencilla, montón de librerías, y sin apenas pérdida de rendimiento, ya que el backend va en lenguajes de más bajo nivel.

Muy recomendable la librería Numba para ciertos cálculos científicos, sobre todo cuando se tengan que hacer muchas veces.

[#71 ppma]

#25 #65 #68
Bibliotecas

[#68 tztxz0]

#38 Sí, pero es que no siempre se usan bien las invocaciones a librerías.

[#73 unomasdelmonton]

#35 echa un ojo también a #38, que también habla del tema.

[#130 lectorcritico]

#13 CPCO4 - Python. Más rápido que C (49:06)

#19 #20 Hay un CMS hecho en C con la motivacion de ahorrar gasto energetico. Estari bien una version o CMS en Rust.
#95 CMS hecho en C++ . Pero no conozco mas en lenguaje de bajo nivel.
http://cppcms.com/wikipp/en/page/rationale

A muchas empresas les compensa ahorrar horas de programacion a costa del hardware, comprar mas y tenerl mas tiempo en uso.
#38 #35 pues hay una charlas de analisis forense que dice que le saca mucho mas rendimiento con Rust que con python. Supongo que son cosas no estandar que hay que diseñar procesos no-standar de bajo nivel.
https://invidious.privacydev.net/watch?v=hhRM-D5xn60

[#12 boikot]

#10 Yo ocupo la posicion de release manager en mi empresa , no se que ves de raro o asombroso. En grandes organizaciones es normal tener a alguien que tome el control de las releases de los distintos equipos / productos aunque vaya un poco en contra de la filosofia CI / CD.

[#16 Desactivado]

#12 ¿pero sería masculino o femenino? ¿Las o los?

[#32 Desactivado]

#16 Los dos.

Se utiliza el término en inglés porque es una posición dentro de un equipo o empresa que se inventó en algún país de habla inglesa.

La documentación y los libros que se escribe sobre ello generalmente también es en inglés, por lo que traducirlo al español haría que la gente no se entendiera entre ella.

[#58 Wajahpantat]

#12 te tocarás los huevos a dos manos, no?

[#63 boikot]

#58 va a dias , pa que nos vamos a engañar

[#13 Yengamatico]

#9 tambien es 40 veces mas rapido desarrollar en python que en c, con el ahorro de costes que supone

[#18 wai]

#13 Mínimo. El desarrollo solo es un pequeño % en el tiempo de vida de un programa.

Si en vez de desarrollar en 100 horas tardas 20 para un programa que va a estar 10 años en cloud consumiendo cpu, dime donde está el ahorro.

Ahora, que si, que el programador se siente superbien porque ha hecho nosequé superápido.

[#19 FooDev]

#18 Eso suponiendo que se va a hacer un uso intensivo de dicho programa y que además el programa hace un uso intensivo de los recursos del sistema. Muchas veces no es así. A veces se trata de una simple web donde para más inri el cuello de botella de lo pone la BBDD (programada en C posiblemente).

[#20 Desactivado]

#19 Un servidor web, como el del meneo, está funcionando las 24 horas.

[#23 FooDev]

#20 Pero todo depende del uso que se le dé. Te aseguro que mis páginas web escritas en cualquier lenguaje interpretado funcionan perfectamente en mi Raspberry.

[#24 Desactivado]

#23 Solo respondía a eso de "según el uso que se le dé". 24 horas de uso diario hacen que cualquier ahorro sea interesante.

[#29 FooDev]

#24 A ver, no. No. Qué esté corriendo y accesible no implica que se le esté dando uso. Un aplicación web idle escrita en Python (que corre sobre un servidor escrito en C) te consume prácticamente lo mismo que una escrita en C.

[#76 hablador_pasivo]

#24 24 horas al día a 1 request por minuto es nada. No ahorras nada aunque lo hagas 100 veces más rápido.

[#79 Desactivado]

#76 No sé cómo habrán podido medir el 25% de nada.

[#83 hablador_pasivo]

#79 eh?

[#43 amchacon]

#20 aparte de lo que te dicen. Ten en cuenta que no hay un único servidor web sino varios.

[#106 zentropia]

#20 Eso no quiere decir que esté procesando requests 24h al día.

[#22 wai]

#19 Que va, sin suponer uso intensivo. Como si se ejecuta una vez al día. El tiempo coste de cpu en 10 años no merece la pena.

Además, que estás suponiendo que el coste de cpu va a ser bajo forever

[#50 Desactivado]

#19 Pues yo no suelo ver que el problema sea el rendimiento de las bases de datos, en la mayoría de aplicaciones comerciales que monitorizo y llevo como 15 clientes.

[#64 FooDev]

#50 Depende del tipo de aplicación pero, por lo general, en las aplicaciones web con las típicas acciones CRUD el cuello de botella está en las BBDD siempre. Gestionar una petición HTTP y que el controlador devuelva una respuesta es una acción casi instantánea, ya se trate de Python, PHP, Java o C. Repito, para aplicaciones con poca concurrencia.

[#81 llorencs]

#64 Con bastante concurrencia Python tiene bibliotecas asíncronas que hacen que pueda ejecutarse con bastante rendimiento. Por ejemplo FastAPI es un buen servidor web asíncrono en Python.

[#33 JoseElTenazas]

#18 ya llegó el típico programador meneante.

* Despliegan en producción 1 vez cada 10 años (deploy early and often? )
* De lo anterior se intuye que nunca aplican actualizaciones de software, ni siquiera las de seguridad.
* Escribir bugs y desplegar parches para los mismos es de débiles.
* Si código es escrito directamente en binario.
* Lo más cerca que han estado de cualquier lenguaje de alto nivel, son los artículos de magnet.xataka.com y genbeta.

Y así nos va. Vaya nivel...

[#39 llorencs]

#33 No hace falta ser borde.

[#45 amchacon]

#39 no es ser borde, es ser directo.

A mí lo que me sorprende esque #_18 tenga tantos votos positivos teniendo en cuenta que no tiene ni idea de desarrollo software.

[#52 Desactivado]

#45 A mi no me parece mal lo que dice. Muchas veces por meter prisa a los desarrolladores se cometen errores que luego tiran para atrás una versión. A veces es absurdo tanta prisa y sale más caro.

[#77 amchacon]

#52 pero eso no tiene nada que ver con lo que ha dicho...

[#87 Desactivado]

#77 Bueno, yo lo entiendo como una critica a las prisas, pero es cierto que le echa la mierda al desarrollador como si pudiera elegir.

[#138 JoseElTenazas]

#39 no es ser borde, es que los comentarios en todo post acerca de Python o de Java son parecidos. Y después de 16+ años ya llega a cansar

[#113 wai]

#89 correcto, el código requiere un mantenimiento que hay que pagarlo.

Yo hablo de costes. Y el precio del mantenimiento es mucho menor que el de desarrollo.

Y el precio de la cpu en entornos virtuales es algo que ningún desarrollador ve ni tiene en cuenta pero que pagar, se paga.

CC #84 #62 #59

#42 10 años llevo programando profesionalmente y otros tantos como estudiante y si, también en python.

#33 ya está el típico que se piensa que todas las empresas funcionan como la suya. Y luego le pones un test de codility o hackerrank en la entrevista y todo son excusas, que en su pueblo se hacia esto o lo otro.

[#42 amchacon]

#18 que el desarrollo supone un pequeño porcentaje...? O no eres programador o tu experiencia en el mundo laboral es nulo.

Los proyectos nunca se acaban. Siempre hay errores o nuevas funcionalidades que aparecen.

Y sí, generalmente es más barato echar más hardware al problema que pagar más programadores. Que igualmente no es cierto porque la diferencia real de programar una aplicación web en Python o en C++ es nula.

[#55 Desactivado]

#42 Creo que se refiere al desarrollo inicial. Pero como dices nunca se termina de verdad de desarrollar una aplicación cuando es compleja, de hecho hoy en día desarrollo, producción y monitorización están muy integrados por esto. Amen de Seguridad, que cada X tiempo y con algunas aplicaciones como Dynatrace en tiempo real, te están reportando vulnerabilidades de seguridad que se deben corregir. Bueno en algunos sitios si es crítica o alta en 15 días o te apagan la aplicación

un saludo.

[#117 amchacon]

#55 esque nunca se acaba de desarrollar una aplicacion.

Yo me acuerdo de una empresa que me pidio un software sencillito. Tan sencillo era que solo me iban a pagar 400€ en la fecha de entrega.

Año y medio despues de la entrega, aun seguia sacando actualizaciones porque pedian mas funcionalidades. Esos 400€ habian pasado a ser casi 8000€ ya.

[#125 Cuñado]

#42 O no eres programador o tu experiencia en el mundo laboral es nulo.

Es una de las lacras de Menéame: la cantidad de "expertos programadores" cuya experiencia se reduce, en el mejor de los casos, a haber copiado un script de alguna web.

El "C es más rápido ergo C es mejor", sin entrar a valorar el para qué, es un síntoma inequívoco de pertenecer a ese selecto grupo.

[#59 RubiaDereBote]

#18 " El desarrollo solo es un pequeño % en el tiempo de vida de un programa."

Debo confesar que se me has sacado una carcajada. El desarrollo de cualquier software es como un cáncer que se extiende durante toda su vida.

#13 ahora bien, así como le digo eso al compañero eso, a ti te digo que en Python hay cosas que se pueden programar muy rápidamente pero también es verdad que por la idiosincrasia del ecosistema Python, donde no se usa el tipado correspondiente ni de casualidad, hace que cualquier error sea una odisea encontrarlo y corregirlo. Eso hace que el tiempo que ahorras por un lado, lo pierdas por el otro con creces. Para mí, los únicos lenguajes que deberían usarse para aplicaciones que van a estar en producción, son aquellos que poseen un fuerte y estático tipado, y que además es obligatorio su uso. Eso es lo que más tiempo ahorra a un programador.
Python está muy bien para prototipado.

[#62 Desactivado]

#18 si eso fuese cierto, no existiría PHP, y todas las empresas programarían todas sus webs directamente en C.

[#84 RamonMercader]

#18 bienvenido a 2022. Ningún software comercial va a estar 10 años en la nube sin cambios.

La industria está transformándose hacia modelos de CI/CD para poder competir (eso en España, en otros sitios y en algunos sectores ya están 100% en ese modelo). El desarrollo es el mayor coste de cualquier producto de software, y con cosas como esta que reducen y optimizan el resto de costes, cada vez será un % mayor.

Y aun diría más, en cuanto las IAs que programen estén más afinadas y sirvan para un uso industrial, en lugar de reducir el número de programadores hará que se pase al siguiente nivel, donde desarrollos de años se hagan en meses y la demanda de software cada más complejo se dispare. Eso acabará haciendo que se necesiten incluso más programadores, ya que con una IA una pequeña empresa va a poder plantearse tener lonque ahora solo tienen las grandes empresas (y estas pasarán al siguiente escalón)

[#89 pawer13]

#18 El desarrollo inicial es el 20% del tiempo, el restante 80% del tiempo que un desarrollador va a estar leyendo y modificando ese código va a ser una vez que esté en producción: bug que se arreglan, modificaciones que se piden, nuevas funcionalidades... a menos que sea un código de usar y tirar, claro (campañas publicitarias, pruebas de concepto...).

[#95 SaulBadman]

#18 Ya, pero la realidad es que la mayoría de servidores corren código en JavaScript, Python, PHP, Java, y demás lenguajes que no son demasiado conocidos por son demasiados conocidos por si eficiencia.

Según tengo entendido, para encontrar C, C++, Rust, y similares en el backend de un servidor tiene que ser algo que maneje flujos de datos enormes, como puedan ser los servidores de YouTube, Netflix y demás

[#127 Cuñado]

#95 Y ni siquiera. Tanto el backend de YouTube como el de Netflix están programados en Python. Lo cual no implica que por supuesto tengan rutinas muy específicas programadas en otros lenguajes para llevar a cabo tareas CPU-intensivas como puede ser la codificación de vídeo. Tareas que, por cierto, son llamadas desde los gestores de tareas... desarrollados en Python.

La excepción a lo que comentas es Rust. Rust sí está teniendo mucha tracción últimamente en el desarrollo web y ya dispone de un ecosistema bastante nutrido en ese campo. Aunque por supuesto a años luz de los de JS, Python o Java.

[#124 blacar]

#18 Plantear que cualquier cosa va a estar 10 años funcionando ... y ademas sin ninguna modificacion ... eso si es scifi

[#136 mirei]

#18 Si tan importante es el rendimiento, siempre puedes escribirlo en Julia, que es prácticamente la misma sintaxis. El rendimiento es varias veces mejor.

https://julialang.org/

[#40 exeware]

#13 40 veces más rapido mis coj...

[#128 Cuñado]

#40 Ok, haz un backend normalito para una web (con acceso a bases de datos relacionales y NoSQL, autenticación OAuth, autorización por roles, gestión de sesiones, gestión de tareas en background, API REST, documentación de la API...) en C y luego ya nos cuentas

[#8 abnog]

Si hiciesen lo mismo con Java solucionaríamos la crisis energética de un plumazo.

[#14 Desactivado]

#8 java es muchísimo más potente que Python

[#37 abnog]

#14 #17 #34

Punto uno: no me jodáis la coña
Y punto dos: Java usa una máquina virtual al igual que Python, no es compilado.

[#54 paco_camps_2011]

#37 #14 #17 #34 Que yo recuerde Java es compilado e interpretado, un punto intermedio.

[#72 AlvaroLab]

#14 #37 #41 #17 Por favor, que alguien habra una batalla de ¿Cuál es el mejor lenguaje de programación? en Menéame. Las batallas políticas de estos foros van a quedar a la altura del betún.

[#74 Desactivado]

#72 el mejor lenguaje de programación? Pues es que eso es como cuando tienes muchos hijos, quién es el mejor? El deportista polovalente , el que hace todo sencillo y fácil, el fuertote del gym, el que todo lo hace bien pero no destaca en nada, el que es tan rápido pero se choca porque no controla en la pista, el que nació viejo ...etc jajaja

[#78 AlvaroLab]

#74 ya lo sé. Por eso encuentro divertido cuando forofos de distintos lenguajes se enzarzan. 😂 😂

[#92 pawer13]

#78 A mi me pone de los nervios presenciar esas discusiones, sobre todo porque todo el mundo defiende el lenguaje que a él le gusta/domina, porque no conoce el resto.

[#97 AlvaroLab]

#92 Y porque se comparan churras con merinas... como se compara un Java para Android, con un Python para backend, con un Javascript para frontend...

[#109 lobomad]

#72 Depende del proyecto, en cada caso puede ser mejor uno u otro, aunque normalmente manda el cliente.

[#41 lobomad]

#14 Y JavaScript, además no recarga el servidor ya que la carga del proceso se realiza en cliente.

El duelo final es entre Python y JavaScript

[#51 ostiayajoder]

#41 Javascript, como python, por ser interpretados, son MUCHISIMO mas consumidores de energia que java.

Y, de hecho, java consume mucho menos que .net (del orden de la mitad, ojo!).

Habia unas graficas por ahi que vi en internet hace uno o dos meses y, de las cuales, me llamo MUCHO la atencion eso: que java consumia poquisima energia (y sin graalVM ni nada)

[#70 JosemiGT]

#51

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html

[#118 ostiayajoder]

#70 LOL si hacen benchmarks podian haber cogido GraalVM y no la VM de OpenJDK...

[#17 pawer13]

#8 Java sigue siendo más eficiente que Python. Gasta más RAM, pero menos CPU

[#34 Desactivado]

#8 Como apunta #17 , los lenguajes compilados son muchísimo más rápidos y consumen bastante menos recursos que los no compilados.

[#112 dark_soul]

#8 si no recuerdo mal existe kotlin. Un lenguaje más moderno 100% compatible con las librerías de java y que es lo que está adoptando Google para el desarrollo de android

[#123 blacar]

#8 Java no tiene ningun problema con el consumo de CPU ... es algo avaricioso y posesivo con la memoria.

[#25 Desactivado]

Las implicaciones energéticas serían enormes si Python se usara directamente en tareas intensivas en CPU, para las cuales nadie elegiría Python.

(Y antes de que me digáis "pues python se usa para inteligencia artificial", responderé que sí, pero el "backend" de todas esas librerías es C/C++).

[#30 tztxz0]

#25 En ciencia se usa mucho python para tareas intensivas en CPU. 

[#35 Desactivado]

#25 (Y antes de que me digáis "pues python se usa para inteligencia artificial", responderé que sí, pero el "backend" de todas esas librerías es C/C++).

Por curiosidad, ¿puedes explicar esto? Gracias

[#36 convidat78]

#35 pues básicamente, cuando usas las bibliotecas numpy/scipy ... en Python para realizar cálculos (o usas MATLAB), muchas veces estas bibliotecas hacen uso de, por ejemplo, las bibliotecas BLAS, lapack, ... vectorización, ... y de hecho en el anuncio de las optimizaciones de la versión 3.11 ya dicen que si tus programas hacen cálculos con numpy no habrá ninguna mejora.

[#15 sillycon]

#3 dice también que es un 25% más rápido.
En cualquier caso Python es un lenguaje interpretado a través de un lenguaje intermedio, al estilo de los bytecodes de Java. Cualquier lenguaje compilado medianamente correcto será mucho más eficaz.

[#48 Heni]

#c-15" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3762231/order/15">#15 No te quito la razón pero desde hace años tanto Java como C# (no sé python) en la primera ejecución de cada parte del código se compila el código intermedio (bytecode o Msil) a código máquina (mediante el just-in-time compiler) y la segunda vez que ejecuta esa parte del código se usa directamente el código compilado en lugar del código intermedio por lo que te rinde igual(o muy parecido) que lenguajes compilados directamente.

Optimizaciones que fueron saliendo con el tiempo

[#140 sillycon]

#48 me alegro de saber que se usa JIT, y me parece perfecto, pero la eficacia de esto siempre ha dependido mucho de la implementación. Cuándo se ejecuta el compilado, si ha habido variaciones, compatibilidad, etc. Mientras vaya bien fantástico, pero es más simple y elegante saltarse toda la complicación y usar lenguajes compilados.

[#142 lectorcritico]

#48 #140 Como curiosidad los lenguajes compilados tiende a compilar en un lenguaje intermedio.
Como LLVM. Puede ser mas rapido y tambien permite hacer un esamblado esperanto, que permita compilar a muchos arquitecturas de CPU
http://www.aosabook.org/en/llvm.html

[#56 exeware]

#15 por supuesto, esa es la clave que es interpretado

[#28 pawer13]

#7 EEE?

[#31 Nostradameus]

#28 Embrace, Extend, Extinguish

[#1 MetalAgm]

https://www.xataka.com/aplicaciones/luz-esta-cara-que-averiguar-cual-lenguaje-programacion-eficiente-buena-idea

[#4 exeware]

#1 python era 79 veces peor que c, margen de maniobra había

[#9 era_mi_primer_dia]

#4 ahora únicamente es 40 veces peor

[#49 paco_camps_2011]

#4 ¿Y consume más o menos que Bitcooin?

[#53 exeware]

#49 deepeendee

[#66 AlvaroLab]

#4 Si conoces Python y conoces C, supongo que también sabes son lenguajes muy distintos. Creo que es un poco injusto compararlos.

Vamos a comparar con Ruby, con PHP... no sé.

[#82 exeware]

#66 conozco ambos, si tu tb los conoces sabrás que son comparables, que uno salga perdiendo no hace la comparación injusta. Hay casos de uso que ambos están muy distantes y otros que son muy similares por ejemplo el esp32 (chip iot) se programaria en C y python no parece pintar nada aqui pero resulta que este chip y otros muchos pueden usar un subset de python.
Pero vamos que la comparación no es idea mía, esta en el artículo donde se comparan unos 20 lenguajes. Además que la comparación se basa en una métrica bien concreta consumo de cpu.
Personalmente por experiencia se que la decisión de que lenguaje usar es algo que obedece a muchos factores, y muchas veces el rendimiento del lenguaje está al final de la lista. Por ejemplo si tu empresa solo hay programadores x, y legacy en x buscarán programarlo en x y si en algún momento cambian a y será por que no encuentran programadores x.

[#90 AlvaroLab]

#82 Bajo mi punto de vista son difícilmente comparables, tanto en tipo de lenguaje como en sus aplicaciones.

[#93 exeware]

#90 en uso de cpu/energía para un mismo uso son comparables 100%. Y otras muchas facetas tb, hay casos de usos que uno de los dos no aplica eso tb lo se.

[#96 AlvaroLab]

#93 Es como comparar, un delantero y un portero. Claro que se pueden comparar... pero... bueno, eso.
Puedes comparar el número de penalties que un portero y un delantero paran, sí. Puedes comparar el número de goles que marcan, sí.

Puedes hacer desarrollo backend web con C, sí. Sería una locura, sí.
Puedes hacer programación de bajo nivel con Python, sí. Sería una locura, sí.

Python es mucho más accesible que C y eso lo hace más lento que C. El cometido de los 2 es muy distinto.

Luego ya... compilado vs interpretado, tipado dinámico vs estático...

[#102 exeware]

#96 c y pyhton sin ambos delanteros! O porteros! Uno mas alto el otro más ágil uno para penaltis el otro juega bien el pie, etc... Son 100% comparables pero para según que caso prefieres un portero u otro así lo veo yo.

[#133 Cuñado]

#93 para un mismo uso

Eso es precisamente en lo que no son comparables. Probablemente, entre los lenguajes más usados, no haya dos con más casos de uso y menos solapamiento entre ellos que Python y C.

[#129 exeware]

#121 en fin pensaba que podríamos debatir como adultos. Si te pierdes por las ramas no es mi problema, en tu comentario #90 dices que no son comparables, aclarate! Todo esto viene del hecho de si c consume más o menos cpu que python y no del scope del lenguaje! Que tienen un scope diferente lo sé pero para poder decir que el python es lento o rápido HAY QUE COMPARARLO con otros lenguajes punto.

[#2 Desactivado]

Sería interesante saber qué cambios han hecho, a nivel de compilador y otros, para lograr eso.

[#3 exeware]

#2 si han reducido consumo sin reducir prestaciones pos si.

[#6 Cuñado]

#2 Pues más fácil no lo puedes tener

Precisamente, el release manager de la 3.11, y miembro de Faster CPython, es español y hace unos meses que dio una charla al respecto en la PyConEs sobre este tema:

[#10 Desactivado]

#6 “Release Manager” toma ya!

[#110 Cuñado]

#10 Imagino que te parecerá extraño porque no trabajas en el sector informático, pero cualquier producto de la complejidad de Python que mantenga varias versiones a la vez necesita uno.

[#122 Desactivado]

#6 Gracias!

[#11 Rexor]

#2 no es muy normal compilar python, las mejoras habrán sido a nivel de intérprete

[#69 AlvaroLab]

#11

De el siguiente artículo - https://zathiro.wordpress.com/2010/08/21/python-lenguaje-semi-interpretado/
"Python tiene, no obstante, muchas de las características de los lenguajes compilados, por lo que se podría decir que es semi interpretado. En Python, como en Java y muchos otros lenguajes, el código fuente se traduce a un pseudo código máquina intermedio llamado bytecode la primera vez que se ejecuta, generando archivos .pyc o .pyo (bytecode optimizado), que son los que se ejecutarán en sucesivas ocasiones."

Supongo que se refiere a eso. No es una compilación al estilo C, pero sí hay un compilador.

[#75 Rexor]

#69 como haber hay módulos de compilación, tengo amigos que los usan, la verdad no los he usado nunca, sólo hago scripts para pentesting. Pero siempre me ha sonado que decir voy a compilar python es como decir voy a compilar php por ejemplo. Por eso hay lenguajes compilados y lenguajes interpretados, la arquitectura es completamente distinta.

[#80 AlvaroLab]

#75 creo que puedes compilar Python si quieres, para optimizar la "compilación" más (yo nunca lo he hecho).

Pero en general, la "compilación" de Python sucede de forma automática, que no quiere decir que no haya un compilador.

[#46 amchacon]

#27 todavía hay aplicaciones que usen Python 2?

[#91 pawer13]

#46 Lamentablemente sí, en mi empresa estamos migrando todavía a Python 3 algunas cosas. Y uno de los motivos es porque no puedes ya programar en Python 2 cómodamente en los nuevos Macs porque no hay builds para la arquitectura del M1.

[#47 BloodStar]

Esto indica que antes el rendimiento era vergonzoso.

Cosa que por otro lado todos ya sabíamos.

[#57 Desactivado]

#47 Si pero python es fácil, para desarrolletes de administrar cosas te vale, te toma poco tiempo y hace su función. A mi me gusta, lo uso para atacar las apis de mi herramienta y hacer informes. También te digo, no soy un experto que me lei un libro de aprende python en un fide y tire "pa lante", pero claro para esas mierdecillas de programas me vale.

[#67 Desactivado]

#57 Y sencillamente hay muchas cosas en las que el rendimiento no importa. Me da igual que un programilla que voy a tener que correr 5 veces en mi vida tarde 2 segundos en vez de 10 ms, el tiempo de respuesta efectivo es el mismo, y la mayor facilidad a la hora de programar es notable.

[#86 Opinator_3.0]

He programado profesionalmente en más de 7 lenguajes, y puedo decir sin ningún género de dudas que Phyton es la mayor mierda que he visto y, para colmo, el que más éxito tiene (entre los que solo conocen ese lenguaje o no les gusta programar). Cuando lo empecé a estudiar, confieso que con cierta ilusión, no salía de mi asombro al constatar que este lenguaje había heredado lo peor de PHP, junto a lo peor de las tabulaciones, sintaxis horrorosa, con $ y _ por todos lados y encima dirás, ya que es feo, tendrá un rendimiento de cojones, pues tampoco. Es un lenguaje fallido para grandes proyectos pero supongo que para tirar cuatro líneas para automatizar algún proceso de sistemas valdrá. O también es usado por cojones, porque alguien tuvo la genial idea de desarrollar buenas librerías de IA en su día.

[#88 llorencs]

#86 Python usando $ por todos lados? Si no lo usa por ningún lado. Y decir que su sintaxis es fea...

Más fea es la sintaxis de Javascript o los derivados de C.

Las tabulaciones son malas? Hacen que el código sea mucho más legible. Dios, como odio programas que no tabulan los bloques y se hacen dificiles de saber donde empieza y termina un bloque. Con las tabulaciones ves visualmente e inmediatamente lo que corresponde a un bloque.

[#94 Opinator_3.0]

#88 Efectivamente, el $ no es un símbolo básico de Python, lo he confundido con %, heredado de la sintaxis C, y que en mi opinión es horrible (hace unos tres años que empecé con Python y no lo he vuelto a tocar, afortunadamente).
Yo también soy un talibán de las tabulaciones pero eso no tiene nada que ver con que el sistema de llaves me parezca más cómodo y visual. Además las llaves permiten en lenguajes más modernos hacer closures , pasar comportamientos como argumento, etc que no creo que pudieran ser implementados sin llaves o algún otro símbolo que marque el inicio y fin de cada bloque. Al decir que no me gusta nada Python no quiero decir que JavaScript u otros lenguajes más veteranos sean más "bonitos", pero para ser Python un lenguaje relativamente reciente me parece bastante obsoleto estéticamente y encima con pobre rendimiento y limitaciones técnicas de despliegue. Si echas un vistazo a Swift o Kotlin, o incluso las últimas versiones de java, dices, joder qué cómodo e intuitivo todo.

[#98 llorencs]

#94 Java no me entra. No lo trago. No hay manera.

En Python puedes hacer "closures" sin ningún problema. Son bastante habituales. Por ejemplo todos los decoradores vendrían de un "closure".

En strings modernos, lo del % no lo usas para nada. Yo nunca he necesitado esa sintaxis. Escribes algo así: f'mi nombre es: ' Y tira millas.

[#99 Opinator_3.0]

#98 ¿Con números tampoco necesitas %?

[#101 llorencs]

#99 No, tampoco.

Ejemplo:
n = 4
print(f'El número es: ')

O puedes hacer algo así:
n2=2
print(f'La suma es: ')

[#107 Desactivado]

#94 "Python reciente" del año 91, hombre joven no es.
Y en esto que dices, pues cuestión de gustos

[#5 Jakeukalane]

Manjaro hace poco iba por la 3.8 o la 3.9; no me imagino la cantidad de cosas que romperán al actualizar esta vez...

editado:

Parece que ya van por la 3.10 pero dudo que esa sea la situación con Ubuntu y Debian que son los sistemas usados en Google Colabs.

[#7 Jakeukalane]

#5 Edit2. ¿EEE de Microsoft contra Python a la vista? Ya lo están haciendo con Linux.

[#21 Desactivado]

#5 Estoy mirando el what's new in Python 3.11 y no veo que haya grandes cambios que joroben la compatibilidad. Nada diferente a lo que encuentras entre versiones que distan 3 o 4 releases. Y puedes tener 3.8 y 3.11 instalados a la vez (aún tengo python 2...).

[#26 llorencs]

#5 #21 Cualquier cosa escrita en Python 3 funciona en las versiones posteriores. Por lo tanto no hay nada de compatibilidad rota, como bien dices. Pero eso sí, hay cosas nuevas en las revisiones que sí que pueden hacer que no funcionen si se ejecutan en Python anteriores. El caso más relevante en Python 3.10 sería el "match", que no existe en versiones anteriores.

[#27 Desactivado]

#26 Y para esos casos (aplicaciones en python que usen match) instalas el python de la versión que lo soporte. Por eso tengo 2 y 3 en mi sistema.

[#60 Aokromes]

#5 python3 --version
Python 3.9.2
debian stable.

[#104 MPR]

#5 Ubuntu 22.10 viene con Python 3.10

[#132 MPR]

#5 Y acabo de comprobar que en Ubuntu 22.10 también está ya disponible la versión 3.11

[#85 samuelCan]

Me gustaría comparar este ahorro con estacionar mi SUV 5 minutos con el motor en marcha.

[#61 ninefingers]

Volvamos a las CGIs en C.

[#100 Malandrico]

En este podcast sale Guido hablando del tema: