Mudanças do Python 2 para o 3 tornam a refatoração do código inevitável

Ter que se deparar com a perspectiva de ter que se aprofundar em um código antigo para fazê-lo funcionar com uma nova versão da linguagem é uma das coisas que os desenvolvedores tentam evitar a todo custo. É difícil entender um código antigo; alterações inesperadas podem introduzir novos bugs, o desempenho provavelmente será prejudicado e é um esforço enorme para um retorno mínimo. Afinal, você não está acrescentando nada de novo, apenas fazendo com que ele funcione como antes. Este post abordará alguns exemplos de mudanças entre o Python 2 e o 3 que tornam essa refatoração de código inevitável.

Então, você tem seu aplicativo em Python 2 funcionando exatamente como planejado. Ele vem funcionando perfeitamente há alguns anos, a equipe de desenvolvimento resolveu todos os problemas, e todos estão satisfeitos com seu desempenho. Ele cumpre sua função e sai de cena quando não é mais necessário.

Mas, do nada, é divulgada uma nova vulnerabilidade que afeta o Python 2. Como o suporte oficial já foi encerrado, não há mais patches de segurança disponíveis; assim, seu fantástico aplicativo, sem ter culpa alguma, agora também está vulnerável e se tornou um risco à segurança da organização. Sendo o gerente de TI diligente que você é, você incumbe sua equipe de desenvolvimento de priorizar a refatoração do código para que ele seja executado em uma versão segura do Python 3.

Sua equipe estava trabalhando em outros projetos, e tudo isso agora está suspenso. É uma decisão que custa caro, mas precisa ser tomada, certo? Leva algumas semanas para reunir todos os detalhes sobre as alterações necessárias no código e como elas afetam outras seções do código — sejam elas inesperadas ou das quais já não se lembra mais. Grande parte da lógica central precisa ser reescrita, já que algumas funcionalidades foram descontinuadas desde o Python 2, e a substituição no Python 3 não é simplesmente substituir e pronto; por isso, novos testes unitários também precisam ser criados.

Mais algumas semanas se passam enquanto os desenvolvedores se esforçam para entender um código mal documentado, escrito por um ex-colega que já não faz mais parte da organização. Parece haver algumas seções de código que “simplesmente funcionam”, mas ninguém entende mais o porquê. Ah, e algumas dependências não são compatíveis com o Python 3 e provavelmente não serão tão cedo — os projetos parecem não ter mais suporte.

Após meses de trabalho árduo, a equipe de desenvolvimento retorna com uma versão “Frankenstein” de uma nova versão do aplicativo. Ela se assemelha um pouco à original; algumas escolhas de interface do usuário dificultam o aproveitamento do conhecimento acumulado, por isso é necessário treinar novamente os operadores.

O desempenho parece ser afetado sempre que alguém aplica alguma alteração no banco de dados. Ninguém sabe ao certo o motivo, mas uma das dependências que teve que ser escrita do zero lidou melhor com isso. E todos os projetos iniciais que a equipe tinha em andamento agora estão atrasados e também ultrapassaram o orçamento.

A equipe voltou com algumas das conclusões, que servirão como conhecimento útil para futuros esforços de refatoração:

Divisão:

Python 3: 5/2 == 2,5

Python 2: 5/2 == 2 (ao substituir “/” por “//”, retorna-se ao comportamento anterior)

A divisão de números inteiros agora retorna um valor do tipo float e não é mais um int.

Imprimir:

Python 3: print(“”)

Python 2: print “”

Alterações no dicionário:

Python 3: os métodos keys(), items() e values() do dict retornam visualizações

Python 2: esses métodos retornam listas. Além disso, os métodos `iterkeys()`, `iteritems` e `itervalues()` não são mais suportados.

Classificação:

Python 3: a função cmp() não deve mais ser usada.

Texto e binário:

Dados de texto e binários são agora conceitos distintos e não devem mais ser armazenados em strings. Algumas operações com strings não funcionam mais em dados nos quais antes funcionavam, pois esses dados contêm caracteres que não são mais permitidos em strings. 

 

Tuplas:

Os parâmetros de tupla não podem mais ser desempacotados como antes.

Várias palavras-chave foram removidas:

“<>” is now “!=”.

Os literais inteiros não funcionam mais com um l ou L de fechamento.

Os literais de string não funcionam mais com um “u” ou “U” de fechamento.

A importação de todos os elementos de um módulo agora só funciona no nível do módulo, e não dentro de uma função.

E muitas, muitas outras mudanças (A lista completa pode ser consultada aqui: https://docs.python.org/3/whatsnew/3.0.html, que serviu de fonte para este artigo).

No final do processo, o aplicativo passou a funcionar pior do que antes; não houve benefícios reais com a migração para um novo nível de linguagem — foram utilizadas apenas construções que substituíram funcionalidades antigas, e nenhum novo recurso avançado, já que o objetivo era apenas fazê-lo funcionar novamente. Foi uma tarefa onerosa que afetou muitas outras atividades em nível organizacional e causou interrupções em todos os níveis.

O que poderia ter sido feito em vez disso?

Existe uma alternativa melhor na forma do Suporte de Ciclo de Vida Estendido para Python. Ao fornecer correções de segurança oportunas sem introduzir alterações no nível da linguagem, o problema poderia ter sido resolvido simplesmente com a implantação do serviço. O mesmo código teria continuado a ser executado tal como está, a vulnerabilidade de segurança teria sido corrigida e todas as outras interrupções poderiam ter sido totalmente evitadas.