uniformizar termos

Author: ramalho

capitulos/cap05.adoc

@@ -531,7 +531,7 @@ que são provavelmente os tipos mais comuns usados para anotar campos em classes
 ==== Nenhum efeito durante a execução
 
 Pense nas dicas de tipo de Python como
-"documentação que pode ser verificada por IDEs e verificadores de tipo".
+"documentação que pode ser verificada por IDEs e checadores de tipos".
 
 Isso porque as dicas de tipo não tem qualquer impacto sobre o comportamento
 de programas em Python durante a execução.
@@ -563,7 +563,7 @@ $ python3 nocheck_demo.py
 Coordinate(lat='Ni!', lon=None)
 ----
 
-O objetivo primário das dicas de tipo é ajudar os verificadores de tipo externos,
+O objetivo primário das dicas de tipo é ajudar os checadores de tipos externos,
 como o https://fpy.li/mypy[Mypy] ou o verificador de tipo embutido do
 https://fpy.li/5-5[PyCharm IDE].
 Essas são ferramentas de análise estática: elas verificam código-fonte Python "parado",
@@ -1029,7 +1029,7 @@ e que o verificador de tipagem Mypy não reclama de nenhuma das duas definiçõe
 A diferença é que aquele `guests: list` significa que `guests` pode ser uma `list`
 de objetos de qualquer tipo, enquanto `guests: list[str]`
 diz que `guests` deve ser uma `list` na qual cada item é uma `str`.
-Isso permite que o verificador de tipos encontre (alguns)
+Isso permite que o checador de tipos encontre (alguns)
 bugs em código que insira itens inválidos na lista, ou que leia itens dali.
 
 A `default_factory` é possivelmente a opção mais comum da função `field`,
@@ -1174,7 +1174,7 @@ chamado `typing.ClassVar`,
 que aproveita a notação de tipos genéricos (`[]`) para definir o tipo da variável
 e também para declará-la como um atributo de classe.
 
-Para fazer felizes tanto o verificador de tipos quando o `@dataclass`,
+Para fazer felizes tanto o checador de tipos quando o `@dataclass`,
 deveríamos declarar o `all_handles` do <<hackerclub_ex>> assim:
 
 [source, py3]

capitulos/cap08.adoc

@@ -69,7 +69,7 @@ Um sistema de tipagem gradual:
 É opcional::
 Por default, o verificador de tipo não deve emitir avisos para código que não tenha dicas de tipo. Em vez disso, o verificador supõe o tipo `Any` quando não consegue determinar o tipo de um objeto. O tipo `Any` é considerado compatível com todos os outros tipos.
 Não captura erros de tipagem durante a execução do código::
-Dicas de tipo são usadas por verificadores de tipo, analisadores de código-fonte (_linters_) e IDEs para emitir avisos. Eles não evitam que valores inconsistentes sejam passados para funções ou atribuídos a variáveis durante a execução. Por exemplo, nada impede que alguém chame
+Dicas de tipo são usadas por checadores de tipos, analisadores de código-fonte (_linters_) e IDEs para emitir avisos. Eles não evitam que valores inconsistentes sejam passados para funções ou atribuídos a variáveis durante a execução. Por exemplo, nada impede que alguém chame
 `tokenie(42)`, apesar da anotação de tipo do argumento `s: str`).
 A chamada ocorrerá, e teremos um erro de execução no corpo da função.
 Não melhora o desempenho::
@@ -83,7 +83,7 @@ tipos recursivos não tinham suporte -- veja as questões https://fpy.li/8-2[#18
 
 É perfeitamente possível que você escreva um ótimo programa Python, que consiga passar por uma boa cobertura de testes, mas ainda assim não consiga acrescentar dicas de tipo que satisfaçam um verificador de tipagem. Não tem problema; esqueça as dicas de tipo problemáticas e entregue o programa!
 
-Dicas de tipo são opcionais em todos os níveis: você pode criar ou usar pacotes inteiros sem dicas de tipo, pode silenciar o verificador ao importar um daqueles pacotes sem dicas de tipo para um módulo onde você use dicas de tipo, e você também pode adicionar comentários especiais, para fazer o verificador de tipos ignorar linhas específicas do seu código.
+Dicas de tipo são opcionais em todos os níveis: você pode criar ou usar pacotes inteiros sem dicas de tipo, pode silenciar o verificador ao importar um daqueles pacotes sem dicas de tipo para um módulo onde você use dicas de tipo, e você também pode adicionar comentários especiais, para fazer o checador de tipos ignorar linhas específicas do seu código.
 
 [TIP]
 ====
@@ -96,7 +96,7 @@ Vamos ((("gradual type system", "in practice", id="GRSpract08"))) ver como a tip
 
 [NOTE]
 ====
-Há muitos((("Python type checkers"))) verificadores de tipo para Python compatíveis com a PEP 484,
+Há muitos((("Python type checkers"))) checadores de tipos para Python compatíveis com a PEP 484,
 incluindo o https://fpy.li/8-4[pytype] do Google,
 o https://fpy.li/8-5[Pyright] da Microsoft,
 o https://fpy.li/8-6[Pyre] do Facebook — além de verificadores incluídos em IDEs como o PyCharm.
@@ -540,7 +540,7 @@ Mesmo que funcione algumas vezes, o nome da função `alert_bird` está incorret
 
 Nesse exemplo bobo, as funções tem uma linha apenas.
 Mas na vida real elas poderiam ser mais longas, e poderiam passar o argumento `birdie` para outras funções, e a origem daquele argumento poderia estar a muitas chamadas de função de distância, tornando difícil localizar a causa do erro durante a execução.
-O verificador de tipos impede que muitos erros como esse aconteçam durante a execução de um programa.
+O checador de tipos impede que muitos erros como esse aconteçam durante a execução de um programa.
 
 
 [NOTE]
@@ -923,7 +923,7 @@ Podemos resumir esse processo em quatro etapas:
 
 . Tornar aquele comportamento o default a partir de Python 3.9: `list[str]` agora funciona sem que  `future` precise ser importado.
 
-. Descontinuar (_deprecate_) todos os tipos genéricos do módulo `typing`.footnote:[Uma de minhas contribuições para a documentação do módulo `typing` foi acrescentar dúzias de avisos de descontinuação, enquanto eu reorganizava as entradas abaixo de https://docs.python.org/pt-br/3/library/typing.html#module-contents["Conteúdo do Módulo"] em subseções, sob a supervisão de Guido van [.keep-together]#Rossum#.] Avisos de descontinuação não serão emitidos pelo interpretador Python, porque os verificadores de tipo devem sinalizar os tipos descontinuados quando o programa sendo verificado tiver como alvo Python 3.9 ou posterior.
+. Descontinuar (_deprecate_) todos os tipos genéricos do módulo `typing`.footnote:[Uma de minhas contribuições para a documentação do módulo `typing` foi acrescentar dúzias de avisos de descontinuação, enquanto eu reorganizava as entradas abaixo de https://docs.python.org/pt-br/3/library/typing.html#module-contents["Conteúdo do Módulo"] em subseções, sob a supervisão de Guido van [.keep-together]#Rossum#.] Avisos de descontinuação não serão emitidos pelo interpretador Python, porque os checadores de tipos devem sinalizar os tipos descontinuados quando o programa sendo verificado tiver como alvo Python 3.9 ou posterior.
 
 . Remover aqueles tipos genéricos redundantes na primeira versão de Python lançada cinco anos após Python 3.9. No ritmo atual, esse deverá ser Python 3.14, também conhecido como Python Pi.
 ****
@@ -1228,7 +1228,7 @@ include::code/08-def-type-hints/replacer.py[tags=ZIP_REPLACE]
 .O TypeAlias Explícito em Python 3.10
 [TIP]
 ====
-https://fpy.li/pep613[PEP 613—Explicit Type Aliases] introduziu um tipo especial, o `TypeAlias`, para tornar as atribuições que criam apelidos de tipos mais visíveis e mais fáceis para os verificadores de tipo.
+https://fpy.li/pep613[PEP 613—Explicit Type Aliases] introduziu um tipo especial, o `TypeAlias`, para tornar as atribuições que criam apelidos de tipos mais visíveis e mais fáceis para os checadores de tipos.
 A partir de Python 3.10, esta é a forma preferencial de criar um apelidos de tipo.
 
 [source, py3]
@@ -1551,7 +1551,7 @@ include::code/08-def-type-hints/comparable/top_test.py[tags=TOP_IMPORT]
 include::code/08-def-type-hints/comparable/top_test.py[tags=TOP_TEST]
 ----
 ====
-<1> A constante `typing.TYPE_CHECKING` é sempre `False` durante a execução do programa, mas os verificadores de tipo fingem que ela é `True` quando estão fazendo a verificação.
+<1> A constante `typing.TYPE_CHECKING` é sempre `False` durante a execução do programa, mas os checadores de tipos fingem que ela é `True` quando estão fazendo a verificação.
 <2> Declaração de tipo explícita para a variável `series`, para tornar mais fácil a leitura da saída do Mypy.footnote:[Sem essa dica de tipo, o Mypy inferiria o tipo de `series` como `Generator[Tuple[builtins.int, builtins.str*&#x5d;, None, None&#x5d;`, que é prolixo mas _consistente-com_ `Iterator[tuple[int, str&#x5d;&#x5d;`, como veremos na <<generic_iterable_types_sec>>.]
 <3> Esse `if` evita que as três linhas seguintes sejam executadas durante o teste.
 <4> `reveal_type()` não pode ser chamada durante a execução, porque não é uma função regular, mas sim um mecanismo de depuração do Mypy - por isso não há `import` para ela. Mypy vai produzir uma mensagem de depuração para cada chamada à pseudo-função `reveal_type()`, mostrando o tipo inferido do argumento.
@@ -1594,12 +1594,12 @@ Found 1 error in 1 file (checked 1 source file)
 A principal vantagem de um tipo protocolo sobre os ABCs é que o tipo não precisa de nenhuma declaração especial para ser _consistente-com_ um tipo protocolo. Isso permite que um protocolo seja criado aproveitando tipos pré-existentes, ou tipos implementados em bases de código que não estão sob nosso controle.
 Eu não tenho que derivar ou registrar `str`, `tuple`, `float`, `set`, etc. com `SupportsLessThan` para usá-los onde um parâmetro `SupportsLessThan` é esperado.
 Eles só precisam implementar `+__lt__+`.
-E o verificador de tipo ainda será capaz de realizar seu trabalho, porque `SupportsLessThan` está explicitamente declarado como um `Protocol`— diferente dos protocolos implícitos comuns no duck typing, que são invisíveis para o verificador de tipos.
+E o verificador de tipo ainda será capaz de realizar seu trabalho, porque `SupportsLessThan` está explicitamente declarado como um `Protocol`— diferente dos protocolos implícitos comuns no duck typing, que são invisíveis para o checador de tipos.
 
 A classe especial `Protocol` foi introduzida na
 https://fpy.li/pep544[PEP 544—Protocols: Structural subtyping (static duck typing)].
 O <<top_protocol_ex>> demonstra((("static duck typing"))) porque esse recurso é conhecido como _duck typing estático_ (_static duck typing_): a solução para anotar o parâmetro `series` de `top` era dizer "O tipo nominal de `series` não importa, desde que ele implemente o método `+__lt__+`."
-Em Python, o duck typing sempre permitiu dizer isso de forma implícita, deixando os verificadores de tipo estáticos sem ação.
+Em Python, o duck typing sempre permitiu dizer isso de forma implícita, deixando os checadores de tipos estáticos sem ação.
 Um verificador de tipo não consegue ler o código fonte em C do CPython, ou executar experimentos no console para descobrir que `sorted` só requer que seus elementos suportem `<`.
 
 Agora podemos tornar o duck typing explícito para os verificadores estáticos de tipo. Por isso faz sentido dizer que `typing.Protocol` nos oferece _duck typing estático_.footnote:[Eu não sei quem inventou a expressão _duck tying estático_, mas ela se tornou mais popular com a linguagem Go, que tem uma semântica de interfaces que é mais parecida com os protocolos de Python que com as interfaces nominais de Java.]
@@ -1796,7 +1796,7 @@ Para encerrar esse capítulo, vamos considerar brevemente os limites das dicas d
 
 === Tipos imperfeitos e testes poderosos
 
-Os mantenedores((("functions, type hints in", "flawed typing and strong testing")))((("type hints (type annotations)", "flawed typing and strong testing")))((("flawed typing")))((("strong testing"))) de grandes bases de código corporativas relatam que muitos bugs são encontrados por verificadores de tipo estáticos, e o custo de resolvê-los é menor que se os mesmos bugs fossem descobertos apenas após o código estar rodando em produção.
+Os mantenedores((("functions, type hints in", "flawed typing and strong testing")))((("type hints (type annotations)", "flawed typing and strong testing")))((("flawed typing")))((("strong testing"))) de grandes bases de código corporativas relatam que muitos bugs são encontrados por checadores de tipos estáticos, e o custo de resolvê-los é menor que se os mesmos bugs fossem descobertos apenas após o código estar rodando em produção.
 Entretanto, é essencial observar que a testagem automatizada era uma prática padrão largamente adotada muito antes da tipagem estática ser introduzida nas empresas que eu conheço.
 
 Mesmo em contextos onde ela é mais benéfica, a tipagem estática não pode ser elevada a árbitro final da correção.
@@ -1854,7 +1854,7 @@ Estudamos genéricos parametrizados e variáveis de tipo, que trazem mais flexib
 Genéricos parametrizáveis se tornam ainda mais expressivos com o uso de `Protocol`.
 Como só surgiu no Python 3.8, `Protocol` ainda não é muito usado - mas é de uma enorme importância.
 `Protocol` permite duck typing estático:
-É a ponte fundamental entre o núcleo de Python, coberto pelo duck typing, e a tipagem nominal que permite a verificadores de tipo estáticos encontrarem bugs.
+É a ponte fundamental entre o núcleo de Python, coberto pelo duck typing, e a tipagem nominal que permite a checadores de tipos estáticos encontrarem bugs.
 
 Ao discutir alguns desses tipos, usamos o Mypy para localizar erros de checagem de tipo e tipos inferidos, com a ajuda da função mágica `reveal_type()` do Mypy.
 
@@ -2018,7 +2018,7 @@ Esse é um custo unitário.
 Mas há também um custo recorrente, eterno.
 
 Nós perdemos um pouco do poder expressivo de Python se insistimos que tudo precisa estar sob a checagem de tipos.
-Recursos maravilhosos como desempacotamento de argumentos — e.g., `config(**settings)`— estão além da capacidade de compreensão dos verificadores de tipo.
+Recursos maravilhosos como desempacotamento de argumentos — e.g., `config(**settings)`— estão além da capacidade de compreensão dos checadores de tipos.
 
 Se você quiser ter uma chamada como `config(**settings)` verificada quanto ao tipo, você precisa explicitar cada argumento.
 Isso me traz lembranças de programas em Turbo Pascal, que escrevi 35 anos atrás.