Mantenedor del sistema de control de versiones. Déjame caer trabajar en la transferencia del proyecto de Python 2 a Python 3. A pesar de que los primeros intentos de migración se realizaron en 2008, y la adaptación acelerada para trabajar con Python 3 comenzó en 2015, la capacidad total de usar Python 3 se implementó solo en las últimas rama de Mercurial 5.2.
Las predicciones sobre la estabilidad del port para Python 3 son decepcionantes. En particular, se espera que aparezcan errores aleatorios en el código a lo largo de varios años, ya que las pruebas no cubren el 100% de la base del código y muchos problemas son invisibles durante el análisis estático y solo aparecen en tiempo de ejecución. Además, muchos complementos y extensiones de terceros siguen sin traducirse a Python 3.
Dado que durante la migración se decidió adaptar gradualmente el código a Python 3, manteniendo el soporte para Python 2, el código adquirió muchos trucos para combinar Python 2 y 3, que deberán limpiarse una vez que finalice el soporte para Python 2.
Al comentar sobre la situación con Python 3, el responsable de Mercurial cree que la decisión de promover Python 3, que rompe la interoperabilidad, e imponerlo como un lenguaje nuevo y más correcto, en ausencia de mejoras importantes que sean relevantes para los desarrolladores, fue un gran error que causó gran daño a la comunidad y es un ejemplo de cómo los grandes proyectos no necesitan hacerlo. En lugar de crear funcionalidades gradualmente y permitir que las aplicaciones se personalicen de forma incremental, el lanzamiento de Python 3 obligó a los desarrolladores a reescribir el código y gastar recursos en mantener ramas separadas para Python 2 y Python 3. No fue hasta siete años después del lanzamiento de Python 3.0 que Python 3.5 introdujo funciones para suavizar el proceso de transición y garantizar que la misma base de código ejecute tanto Python 2 como Python 3.
Fuente: opennet.ru