Python 3.8: o que vem por ai
Novidades sobre a nova versão do Python
Olá pessoal, o Python 3.8 está programado para aterrisar lá pra outubro de 2019 — mas já tem algumas coisas legais no forno. Seguindo a tendência da versão atual a que está por vir trará novos ganhos de performance, sepultando de vez a desculpa preferida dos procrastinadores de upgrades: a de que Python 3 é mais lento do que Python legacy (de agora em diante vou chamar Python 2.x de Python legacy).
Alguns métodos da biblioteca padrão 30–70% mais rápidos
Graças a alguém chamado Serhiy Storchaka os métodos que tem apenas argumentos posicionais estão de 30 a 70% mais rápidos no Python 3.8. A otimização aplicada por Serhiy se chama “Argument Clinic inlining parsing code” e funciona para funções que chamam PyArg_ParseTuple() and _PyArg_ParseStack(). Basicamente essa melhoria economiza o tempo gasto para interpretar format strings e na chamada de alguns níveis de funções — como vocês sabem chamada de função é uma operação relativamente cara em Python comparando com outras linguagens…
De quebra ainda economiza um pouco da C stack por causa do número menor the chamadas aninhadas (e potencialmente recursivas), número menor de variáveis e por evitar stack alocada para arrays de “objects” que não precisam ser de-alocados ou limpos se a operação de parsing falhar.
PyArg_ParseTuple() e _PyArg_ParseStack() ainda serão usadas se houver parâmetros para os quais a operação de “inlining” não é suportada. Estes conversores não suportados são os obsoletos Py_UNICODE API (“u”, “Z”), encoded strings (“es”, “et”), obsolete string/bytes converters (“y”, “s#”, “z#”), e alguns outros conversores personalizados (DWORD, HANDLE, pid_t, intptr_t).
Nada mal Serhiy!!! Pra quem quiser saber mais sobre a melhoria basta dar uma olhada na PR do Issue35582 ou a discussão no reddit. E podem aguardar otimizações semelhantes para keyword arguments, argumentos opcionais e etc.
Filesystem cache paralelo para arquivos de bytecode compilados
A nova chave de configuração PYTHONPYCACHEPREFIX (também disponível como -X pycache_prefix) configura o cache implícito de bytecode para usar uma árvore de paralela no filesystem em vez da pasta default .__pycache__ criada em cada diretório dos fontes.
A localização do cache é reportada na variável sys.pycache_prefix (None indica o local padrão nos subdiretórios __pycache__). Cortesia de Carl Mayer.
Continue dentro de um Finally
O statement continue era ilegal dentro de uma cláusula finally por causa de um problema de implementação. No Python 3.8 essa restrição foi removida. Novamente graças ao Serhiy Storchaka, o cara é quente.
Módulo JSON
Você já usou o macete -m json.tool na linha de comando? É muito útil. Suponha que você está acessando uma API que retorna JSON usando cURL:
As vezes a saída vem sem formatação: {“foo”: 1, “bar”: 2} — aí entra o macete:
curl https://httpbin.org/get | python -m json.tool
Passe a o retorno da API pelo json.tool e a saída vai ficar formatada. A novidade na versão 3.8 é que você pode passar um parâmetro --json-lines que serve para tratar cada linha de entrada como um objeto JSON separado.
Outras mudanças que achei interessantes
- AsyncIO: no Windows o event loop default agora é ProactorEventLoop.
- Gettext: adicionadas
pgettext()e suas variações - Gzip: adicionado o parâmetro mtime em gzip.compress() para permitir uma saída determinística.
- Yield: claro que vocês são meninos educados e não usam list comprehensions ou generator expressions só pelos efeitos colaterais, certo? Bom, por via das dúvidas no Python 3.8 titio Serhiy proibiu uma expressão yield (tanto yield como yield from) de serem usadas dentro de list comprehensions e generator expressions.
Conclusão
A lista de mudanças é muito maior, claro. Para beber direto na fonte veja o What’s New In Python 3.8.
Estou tentando postar um artigo por semana para manter o “weekly” no nome do blog mas é um compromisso e tanto. Se você gosta de escrever sobre tecnologia seria uma honra repostar seus artigos no PWB. Um grande abraço e até a semana que vem (ou a semana que der!).
