uniformizar termos

Author: ramalho

capitulos/cap02.adoc

@@ -1052,7 +1052,7 @@ e ambos os itens da tupla devem ser instâncias de `float`:
 ====
 As expressões `str(name)` e `float(lat)` se parecem com chamadas a construtores,
 que usaríamos para converter `name` e `lat` para `str` e `float`.
-Mas no contexto de um padrão, aquela sintaxe faz uma verificação de tipo durante a execução do programa:
+Mas no contexto de um padrão, aquela sintaxe faz uma checagem de tipos durante a execução do programa:
 o padrão acima vai casar com uma sequência de quatro itens,
 na qual o item 0 deve ser uma `str` e o item 3 deve ser um par de números de ponto flutuante.
 Além disso, a `str` no item 0 será vinculada à variável `name`

capitulos/cap05.adoc

@@ -552,7 +552,7 @@ Veja o <<no_runtime_check_ex>>.
 Coordinate(lat='Ni!', lon=None)    # <1>
 ----
 ====
-<1> Eu avisei: não há verificação de tipo durante a execução!
+<1> Eu avisei: não há checagem de tipos durante a execução!
 
 Se você incluir o código do <<no_runtime_check_ex>> em um módulo de Python,
 ela vai rodar e exibir uma `Coordinate` sem sentido, e sem gerar qualquer erro ou aviso:
@@ -827,7 +827,7 @@ Novamente, `a` e `b` são atributos de instância,
 e `c` é um atributo de classe obtido através da instância.
 
 Como mencionado, instâncias de `DemoDataClass` são mutáveis—e
-nenhuma verificação de tipo é realizada durante a execução:
+nenhuma checagem de tipos é realizada durante a execução:
 
 [source, pycon]
 ----
@@ -904,7 +904,7 @@ tanto o argumento `eq` quanto o `frozen` forem `True`, `@dataclass` produz um m
 O `+__hash__+` gerado usará dados de todos os campos que não forem
 individualmente excluídos usando uma opção de campo, que veremos na <<field_options_sec>>.
 Se `frozen=False` (o default), `@dataclass` definirá `+__hash__+` como `None`,
-sinalizando que as instâncias não são hashable, e portanto sobrepondo o `+__hash__+` de qualquer superclasse.
+sinalizando que as instâncias não são hashable, e portanto sobrescrevendo o `+__hash__+` de qualquer superclasse.
 
 A https://fpy.li/pep557[PEP 557—Data Classes (_Classe de Dados_)] (EN) diz o seguinte sobre `unsafe_hash`:
 

capitulos/cap06.adoc

@@ -319,7 +319,7 @@ e o processamento é tão simples quanto comparar dois IDs inteiros.
 Por outro lado, `a == b` é açúcar sintático para `+a.__eq__(b)+`.
 O método `+__eq__+`, herdado de `object`, compara os IDs dos objetos,
 então produz o mesmo resultado de `is`.
-Mas a maioria dos tipos embutidos sobrepõe `+__eq__+` com implementações mais úteis,
+Mas a maioria dos tipos embutidos sobrescreve `+__eq__+` com implementações mais úteis,
 que levam em consideração os valores dos atributos dos objetos.
 A determinação da igualdade pode envolver muito processamento--por exemplo,
 quando se comparam coleções grandes ou estruturas aninhadas com muitos níveis.

capitulos/cap07.adoc

@@ -288,7 +288,7 @@ Métodos embutidos:: Métodos((("methods, as callable objects"))) implementados
 Métodos:: Funções definidas no corpo de uma classe.
 
 Classes:: Quando((("classes", "as callable objects"))) invocada, uma classe executa seu método
-`+__new__+` para criar uma instância, e a seguir `+__init__+`, para inicializá-la. Então a instância é devolvida ao usuário. Como não existe um operador `new` no Python, invocar uma classe é como invocar uma função.footnote:[Invocar uma classe normalmente cria uma instância daquela mesma classe, mas outros comportamentos são possíveis, sobrepondo o `+__new__+`. Veremos um exemplo disso na <<flexible_new_sec>>.]
+`+__new__+` para criar uma instância, e a seguir `+__init__+`, para inicializá-la. Então a instância é devolvida ao usuário. Como não existe um operador `new` no Python, invocar uma classe é como invocar uma função.footnote:[Invocar uma classe normalmente cria uma instância daquela mesma classe, mas outros comportamentos são possíveis, sobrescrevendo o `+__new__+`. Veremos um exemplo disso na <<flexible_new_sec>>.]
 
 Instâncias de classe:: Se uma classe define um método `+__call__+`, suas instâncias podem então ser invocadas como funções—esse é o assunto da próxima seção.
 

capitulos/cap08.adoc

@@ -123,7 +123,7 @@ include::code/08-def-type-hints/messages/no_hints/messages.py[tags=SHOW_COUNT]
 
 ==== Usando o Mypy
 
-Para começar a verificação de tipo, rodamos o comando `mypy` passando o módulo _messages.py_ como parâmetro:
+Para começar a checagem de tipos, rodamos o comando `mypy` passando o módulo _messages.py_ como parâmetro:
 
 [source]
 ----
@@ -411,7 +411,7 @@ Mas no corpo da função, o verificador considera a chamada `birdie.quack()` ile
 Não interessa que o argumento real, durante a execução, é um `Duck`, porque a tipagem nominal é aplicada de forma estática. O verificador de tipo não executa qualquer pedaço do programa, ele apenas lê o código-fonte.
 Isso é mais rígido que _duck typing_, com a vantagem de capturar alguns bugs durante o desenvolvimento, ou mesmo em tempo real, enquanto o código está sendo digitado em um IDE.
 
-O <<birds_module_ex>> é um exemplo bobo que contrapõe duck typing e tipagem nominal, bem como verificação de tipo estática e comportamento durante a execução.footnote:[Muitas vezes a herança é sobreutilizada e difícil de justificar em exemplos que, apesar de realistas, são muito simples. Então por favor aceite esse exemplo com animais como uma rápida ilustração de sub-tipagem.]
+O <<birds_module_ex>> é um exemplo bobo que contrapõe duck typing e tipagem nominal, bem como checagem de tipos estática e comportamento durante a execução.footnote:[Muitas vezes a herança é sobreutilizada e difícil de justificar em exemplos que, apesar de realistas, são muito simples. Então por favor aceite esse exemplo com animais como uma rápida ilustração de sub-tipagem.]
 
 [[birds_module_ex]]
 ._birds.py_

capitulos/cap11.adoc

@@ -790,7 +790,7 @@ Para modificar um atributo de classe, é preciso redefini-lo diretamente na clas
 Porém, no Python, há uma maneira idiomática de obter um efeito mais permanente, e de ser mais explícito sobre a modificação. Como atributos de classe são públicos, eles são herdados por subclasses. Então é uma prática comum fazer a subclasse customizar um atributo da classe. As views baseadas em classes do Django usam amplamente essa técnica. O <<typecode_subclass_demo>> mostra como se faz.
 
 [[typecode_subclass_demo]]
-.O `ShortVector2d` é uma subclasse de `Vector2d`, que apenas sobrepõe o `typecode` default
+.O `ShortVector2d` é uma subclasse de `Vector2d`, que apenas sobrescreve o `typecode` default
 ====
 [source, pycon]
 ----

capitulos/cap12.adoc

@@ -771,7 +771,7 @@ Protocolos como interfaces informais
 
 Protocolos((("Soapbox sidebars", "protocols as informal interfaces")))((("sequences, special methods for", "Soapbox discussion", id="SSMsoap12")))((("protocols", "as informal interfaces", secondary-sortas="informal interfaces")))((("interfaces", "protocols as informal"))) não são uma invenção de Python. Os criadores de Smalltalk, que também cunharam a expressão "orientado a objetos", usavam "protocolo" como um sinônimo para aquilo que hoje chamamos de interfaces. Alguns ambientes de programação Smalltalk permitiam que os programadores marcassem um grupo de métodos como um protocolo, mas isso era meramente um artefato de documentação e navegação, e não era imposto pela linguagem. Por isso acredito que "interface informal" é uma explicação curta razoável para "protocolo" quando falo para uma audiência mais familiar com interfaces formais (e impostas pelo compilador).
 
-Protocolos bem estabelecidos ou consagrados evoluem naturalmente em qualquer linguagem que usa tipagem dinâmica (isto é, quando a verificação de tipo acontece durante a execução), porque não há informação estática de tipo em assinaturas de métodos e em variáveis. Ruby é outra importante linguagem orientada a objetos que tem tipagem dinâmica e usa protocolos.
+Protocolos bem estabelecidos ou consagrados evoluem naturalmente em qualquer linguagem que usa tipagem dinâmica (isto é, quando a checagem de tipos acontece durante a execução), porque não há informação estática de tipo em assinaturas de métodos e em variáveis. Ruby é outra importante linguagem orientada a objetos que tem tipagem dinâmica e usa protocolos.
 
 Na documentação de Python, muitas vezes podemos perceber que um protocolo está sendo discutido pelo uso de linguagem como "um objeto similar a um arquivo". Isso é uma forma abreviada de dizer "algo que se comporta como um arquivo, implementando as partes da interface de arquivo relevantes ao contexto".
 

capitulos/cap13.adoc

@@ -56,7 +56,7 @@ Não faz sentido descartar qualquer uma delas.
 
 [[type_systems_described]]
 .A metade superior descreve abordagens de checagem de tipo durante a execução usando apenas o interpretador Python; a metade inferior requer um verificador de tipo estático externo, como o Mypy ou um IDE como o PyCharm. Os quadrantes da esquerda se referem a tipagem baseada na estrutura do objeto - isto é, dos métodos oferecidos pelo objeto, independente do nome de sua classe ou superclasses; os quadrantes da direita dependem dos objetos terem tipos explicitamente nomeados: o nome da classe do objeto, ou o nome de suas superclasses.
-image::images/flpy_1301.png[Quatro abordagens para verificação de tipo]
+image::images/flpy_1301.png[Quatro abordagens para checagem de tipos]
 
 Cada uma dessas quatro abordagens dependem de interfaces para funcionarem,
 mas a tipagem estática pode ser implementada de forma limitada usando apenas tipos concretos em vez de abstrações de interfaces como protocolos e classes base abstratas.
@@ -679,7 +679,7 @@ Observe que iterator é subclasse de `Iterable`. Discutimos melhor isso adiante,
 
 `Callable`, `Hashable`::
 Essas não são coleções, mas `collections.abc` foi o primeiro pacote a definir ABCs na biblioteca padrão, e essas duas foram consideradas importante o suficiente para [.keep-together]#serem# incluídas.
-Elas suportam a verificação de tipo de objetos que precisam ser "chamáveis" ou [.keep-together]#hashable#.
+Elas suportam a checagem de tipos de objetos que precisam ser "chamáveis" ou [.keep-together]#hashable#.
 
 Para a detecção de 'callable', a função nativa `callable(obj)` é mais conveniente que `insinstance(obj, Callable)`.
 
@@ -1146,7 +1146,7 @@ Vimos algo sobre protocolos estáticos((("protocols", "static protocols", id="Ps
 em <<protocols_in_fn>> (<<ch_type_hints_def>>).
 Até considerei deixar toda a discussão sobre protocolos para esse capítulo,
 mas decidi que a apresentação inicial de dicas de tipo em funções precisava incluir protocolos, pois o duck typing é uma parte essencial de Python,
-e verificação de tipo estática sem protocolos não consegue lidar muito bem com as APIs pythônicas.
+e checagem de tipos estática sem protocolos não consegue lidar muito bem com as APIs pythônicas.
 ====
 
 Vamos encerrar esse capítulo ilustrando os protocolos estáticos com dois exemplos simples, e uma discussão sobre as ABCs numéricas e protocolos.
@@ -1324,7 +1324,7 @@ então o Mypy pode inferir que dentro do bloco `if`, o tipo do objeto `o` é _co
 [[duck_typing_friend_box]]
 .O Duck Typing É Seu Amigo
 ****
-Durante((("duck typing"))) a execução, muitas vezes o duck typing é a melhor abordagem para verificação de tipo:
+Durante((("duck typing"))) a execução, muitas vezes o duck typing é a melhor abordagem para checagem de tipos:
 em vez de chamar `isinstance` ou `hasattr`, apenas tente realizar as operações que você precisa com o objeto, e trate as exceções conforme necessário. Aqui está um exemplo concreto:
 
 Continuando a discussão anterior: dado um objeto `o` que eu preciso usar como número complexo,
@@ -1438,9 +1438,9 @@ O problema específico com o tipo `complex` foi resolvido no Python 3.10.0b4, co
 Mas o problema geral persiste:
 Verificações com `isinstance`/`issubclass` só olham para a presença ou ausência de métodos,
 sem checar sequer suas assinaturas, muito menos suas anotações de tipo.
-E isso não vai mudar tão cedo, porque este tipo de verificação de tipo durante a execução traria um custo de processamento inaceitável.footnote:[Agradeço a Ivan Levkivskyi,
+E isso não vai mudar tão cedo, porque este tipo de checagem de tipos durante a execução traria um custo de processamento inaceitável.footnote:[Agradeço a Ivan Levkivskyi,
 co-autor da https://fpy.li/pep544[PEP 544] (sobre Protocolos),
-por apontar que checagem de tipo não é apenas uma questão de verificar se o tipo de `x` é `T`: é sobre determinar que o tipo de `x` é _consistente-com_ `T`, o que pode ser caro. Não é de se espantar que o Mypy leve alguns segundos para fazer uma verificação de tipo, mesmo em scripts Python curtos.]
+por apontar que checagem de tipo não é apenas uma questão de verificar se o tipo de `x` é `T`: é sobre determinar que o tipo de `x` é _consistente-com_ `T`, o que pode ser caro. Não é de se espantar que o Mypy leve alguns segundos para fazer uma checagem de tipos, mesmo em scripts Python curtos.]
 ====
 
 Agora veremos como implementar um protocolo estático em uma classe definida pelo usuário.
@@ -1484,7 +1484,7 @@ True
 Vector2d(3.0, 4.0)
 ----
 
-Para verificação de tipo durante a execução, o <<ex_vector2d_complex_v4>> serve bem,
+Para checagem de tipos durante a execução, o <<ex_vector2d_complex_v4>> serve bem,
 mas para uma cobertura estática e relatório de erros melhores com o Mypy, os métodos
 `+__abs__+`, `+__complex__+`, e `fromcomplex` deveriam receber dicas de tipo, como mostrado no <<ex_vector2d_complex_v5>>.
 
@@ -1652,7 +1652,7 @@ Para encerrar o capítulo, vamos olhar as ABCs numéricas e sua possível substi
 [[numbers_abc_proto_sec]]
 ==== As ABCs em numbers e os novos protocolos numéricos
 
-Como((("static protocols", "numbers ABCS and numeric protocols", id="SPnumbers13")))((("numbers ABCs", id="number13")))((("numeric protocols", id="numpro13")))((("protocols", "numeric", id="Pnum13"))) vimos em <<numeric_tower_warning>>, as ABCs no pacote `numbers` da biblioteca padrão funcionam bem para verificação de tipo durante a execução.
+Como((("static protocols", "numbers ABCS and numeric protocols", id="SPnumbers13")))((("numbers ABCs", id="number13")))((("numeric protocols", id="numpro13")))((("protocols", "numeric", id="Pnum13"))) vimos em <<numeric_tower_warning>>, as ABCs no pacote `numbers` da biblioteca padrão funcionam bem para checagem de tipos durante a execução.
 
 Se você precisa verificar um inteiro, pode usar `isinstance(x, numbers.Integral)` para aceitar `int`, `bool` (que é subclasse de `int`) ou outros tipos inteiros oferecidos por bibliotecas externas que registram seus tipos como subclasses virtuais das ABCs de `numbers`.
 Por exemplo, o NumPy tem https://fpy.li/13-39[21 tipos inteiros] — bem como várias variações de tipos de ponto flutuante registrados como `numbers.Real`, e números complexos com várias amplitudes de bits, registrados como `numbers.Complex`.
@@ -1748,7 +1748,7 @@ No momento em que escrevo isso, o NumPy não tem dicas de tipo, então seus tipo
 Por outro lado, o Mypy de alguma maneira "sabe" que o `int` e o `float` embutidos podem ser convertidos para `complex`,
 apesar de, no _typeshed_, apenas a classe embutida `complex` ter o método `+__complex__+`.footnote:[Isso é uma mentira bem intencionada da parte do typeshed: a partir de Python 3.9, o tipo embutido `complex` na verdade não tem mais um método `+__complex__+`.]
 
-Concluindo, apesar((("numeric types", "checking for convertibility"))) da impressão que a verificação de tipo para tipos numéricos não deveria ser difícil,
+Concluindo, apesar((("numeric types", "checking for convertibility"))) da impressão que a checagem de tipos para tipos numéricos não deveria ser difícil,
 a situação atual é a seguinte:
 as dicas de tipo da PEP 484
 https://fpy.li/cardxvi[evitam] (EN) a torre numérica
@@ -1764,8 +1764,8 @@ Se você não usa números complexos, pode confiar naqueles protocolos em vez da
 
 As principais lições dessa seção são:
 
-* As ABCs de `numbers` são boas para verificação de tipo durante a execução, mas inadequadas para tipagem estática.
-* Os protocolos numéricos estáticos `SupportsComplex`, `SupportsFloat`, etc. funcionam bem para tipagem estática, mas são pouco confiáveis para verificação de tipo durante a execução se números complexos estiverem envolvidos.
+* As ABCs de `numbers` são boas para checagem de tipos durante a execução, mas inadequadas para tipagem estática.
+* Os protocolos numéricos estáticos `SupportsComplex`, `SupportsFloat`, etc. funcionam bem para tipagem estática, mas são pouco confiáveis para checagem de tipos durante a execução se números complexos estiverem envolvidos.
 
 Estamos agora prontos para uma rápida revisão do que vimos nesse capítulo.((("", startref="Pstatic13")))((("", startref="Pnum13")))((("", startref="numpro13")))((("", startref="number13")))((("", startref="SPnumbers13")))
 
@@ -1924,8 +1924,8 @@ A <<type_systems_languages>> é((("Soapbox sidebars", "typing map")))((("typing
 com os nomes de algumas linguagem populares que suportam cada um dos modos de tipagem.
 
 [[type_systems_languages]]
-.Quatro abordagens para verificação de tipo e algumas linguagens que as usam.
-image::images/flpy_1308.png[Quatro abordagens para verificação de tipo e algumas linguagens que as usam.]
+.Quatro abordagens para checagem de tipos e algumas linguagens que as usam.
+image::images/flpy_1308.png[Quatro abordagens para checagem de tipos e algumas linguagens que as usam.]
 
 TypeScript e Python ≥ 3.8 são as únicas linguagem em minha pequena e arbitrária amostra que suportam todas as quatro abordagens.