O preço da migração do Mercurial para Python 3 pode ser um rastro de erros inesperados.

Mantenedor do sistema de controle de versão mercurial me decepcione resultado trabalhar na transferência do projeto de Python 2 para Python 3. Apesar de as primeiras tentativas de portabilidade terem sido feitas em 2008 e a adaptação acelerada para trabalhar com Python 3 ter começado em 2015, a capacidade total de usar Python 3 foi implementada apenas nos últimos ramo do Mercurial 5.2.

As previsões sobre a estabilidade da porta para Python 3 são decepcionantes. Em particular, espera-se que erros aleatórios apareçam no código ao longo de vários anos, uma vez que os testes não cobrem 100% da base de código e muitos problemas são invisíveis durante a análise estática e só aparecem em tempo de execução. Além disso, muitos complementos e extensões de terceiros permanecem sem tradução para o Python 3.
Como durante a portabilidade foi decidido adaptar gradativamente o código para Python 3, mantendo o suporte para Python 2, o código adquiriu muitos hacks para combinar Python 2 e 3, que deverão ser limpos após o término do suporte para Python 2.

Comentando a situação com o Python 3, o mantenedor do Mercurial acredita que a decisão de promover o Python 3, que quebra a interoperabilidade, e impô-lo como uma linguagem nova e mais correta, na ausência de melhorias inovadoras relevantes para os desenvolvedores, foi um grande erro que causou grande dano à comunidade e é um exemplo de como não é necessário fazê-lo em grandes projetos. Em vez de construir funcionalidades gradualmente e permitir que os aplicativos fossem personalizados de forma incremental, o lançamento do Python 3 forçou os desenvolvedores a reescrever o código e gastar recursos mantendo ramificações separadas para Python 2 e Python 3. Somente sete anos após o lançamento do Python 3.0 é que O Python 3.5 introduziu recursos para suavizar o processo de transição e garantir que a mesma base de código execute o Python 2 e o Python 3.

Fonte: opennet.ru

Adicionar um comentário