O prezo da migración de Mercurial a Python 3 pode ser unha pista de erros inesperados.

Mantedor do sistema de control de versións Mercurial deséxame total traballar na transferencia do proxecto de Python 2 a Python 3. A pesar de que os primeiros intentos de portabilidade realizáronse en 2008 e a adaptación acelerada para traballar con Python 3 comezou en 2015, a capacidade total de usar Python 3 só se implementou no último rama do Mercurial 5.2.

As previsións sobre a estabilidade do porto para Python 3 son decepcionantes. En particular, espérase que aparezan erros aleatorios no código ao longo de varios anos, xa que as probas non cobren o 100% da base de código, e moitos problemas son invisibles durante a análise estática e só aparecen no tempo de execución. Ademais, moitos complementos e extensións de terceiros seguen sen traducir a Python 3.
Dado que durante a portabilidade decidiuse adaptar gradualmente o código a Python 3, mantendo o soporte para Python 2, o código adquiriu moitos hacks para combinar Python 2 e 3, que terán que ser limpos despois de que remate o soporte de Python 2.

Comentando a situación con Python 3, o mantedor de Mercurial cre que a decisión de promover o Python 3 que rompe a interoperabilidade e impoñera como unha linguaxe nova e máis correcta, a falta de melloras innovadoras relevantes para os desenvolvedores, foi un gran erro que provocou gran dano para a comunidade e é un exemplo de que os grandes proxectos non teñen que facelo. En lugar de construír gradualmente funcionalidades e permitir que as aplicacións se personalizan de forma incremental, o lanzamento de Python 3 obrigou aos desenvolvedores a reescribir código e gastar recursos mantendo ramas separadas para Python 2 e Python 3. Non foi ata sete anos despois do lanzamento de Python 3.0 que Python 3.5 introduciu funcións para suavizar o proceso de transición e garantir que a mesma base de código executa Python 2 e Python 3.

Fonte: opennet.ru

Engadir un comentario