Thread by @osantana

Hoje eu vi uma ferramentas pra usar com Type Annotation no Python que me parecem servir pra passar batom em porco (github.com/dry-python/ret…). A PEP-505 também me motivou a escrever isso aqui...

Segura que lá vem textão... segue o fio...

Se você tem uma chamada para uma função/método `get_abobrinha_by_id(id=...)` no seu código, fica claro pra quem está lendo esse código que ela retorna um objeto do tipo `Abobrinha` que tem o `id` especificado. Não precisa de anotação pra deixar isso mais claro.

Mas se sua função não encontrar o objeto com o `id` solicitado? O que ela deveria retornar? E é aqui que entra o problema. Alguns desenvolvedores fazem a função retornar `None`. E agora sua função retorna 2 tipos diferentes de objeto: `Abobrinha` e `NoneType`.

Já não fica tão claro o que sua função retorna baseado só na chamada dela. Então qual é a solução? Uma delas seria documentar ou "anotar" a função e lembrar de adicionar um null-check (None-check) após cada chamada dessa função.

Outra opção (minha preferida) é manter a interface da função mais "enxuta" de modo que ela só retorne objetos `Abobrinha`. Em um cenário excepcional (hint!) onde eu não encontro o objeto pelo seu `id` eu levantaria uma Custom Domain Exception do tipo `AbobrinhaNotFound`.

Qual a diferença? Se eu esqueço do null-check no primeiro cenário eu posso, em alguns casos, ter uma falha silenciosa no meu código.

No segundo cenário, se eu esqueço de tratar a Exception meu sistema quebra de forma mais clara.

Vejam: não tem certo e errado aqui. É questão de estilo.

E aqui vem uma opinião polêmica sobre as recentes adições à linguagem Python. Estou falando de coisas como async constructions, type annotations, walrus operators, etc e coisas que ainda estão por vir como None-aware operators.(python.org/dev/peps/pep-0…)

Eu acho que cada linguagem tem seu "estilo de nascimento". Com o sucesso dessa linguagem, ela vai recebendo desenvolvedores de outras linguagens. Esses desenvolvedores trazem as coisas boas na bagagem mas também trazem seus cacoetes.

Eles começam a tentar replicar o estilo de suas antigas ferramentas na linguagem nova e esse estilo acaba não combinando.

Anos atrás era comum ver gente desenvolvendo código Java em Python. Tava tudo lá... interfaces, javadoc, estiloDeCodigo(), etc

Os designers da linguagem, no desejo de acolher esses desenvolvedores, acham que devem acrescentar coisas à ela. E, na minha opinião, essas coisas vão aumentando a complexidade da linguagem fazendo com que ela deixe de ser simples. E simples é elegante.

Coisas como a PEP-505 (None-aware operators) parecem ser criadas para agradar desenvolvedores JS/Swift/etc que sempre desenvolveram código com null-check porque exceptions, nessas linguagens, são... complicadas... e agora tentam programar do mesmo jeito em Python

Programando desse jeito eles precisam fazer null-check em todos os lugares e, nesse caso, os operadores em questão são realmente úteis. Mas e se eles usassem um estilo baseado em exception handling?

Todos amigos pythonistas sabem que eu evito muito trazer o adjetivo "pythônico" para o debate porque acho esse termo muito vago. Mas se eu precisasse dar um exemplo prático do que *eu* acho pythônico eu diria que usar exception no lugar de None é um bom exemplo.