cap08: rev LR

Author: ramalho

capitulos/cap01.adoc

@@ -252,7 +252,7 @@ Card(rank='Q', suit='hearts')
 Sempre((("doctest package", "ellipsis in")))((("ellipsis (…)")))((("… (ellipsis)"))) que possível,
 extraí as listagens do console de Python usadas neste livro com o
 https://fpy.li/2e[`doctest`], para garantir a precisão.
-Quando a saída era longa demais, a parte omitida está marcada por reticências (`...`),
+Quando a saída era longa demais, a parte omitida está marcada por reticências (`\...`),
 como na última linha do trecho de código anterior.
 
 Nesse casos, usei((("+ELLIPSIS directive"))) a diretiva `# doctest: +ELLIPSIS`

capitulos/cap02.adoc

@@ -1446,9 +1446,9 @@ eu não escrevi ao contrário: o nome da classe `ellipsis` realmente se escreve
 e a instância é um objeto embutido chamado `Ellipsis`,
 da mesma forma que `bool` é em minúsculas mas suas instâncias são `True` e `False`.]
 Dessa forma, ele pode ser passado como argumento para funções e como parte da especificação de uma fatia,
-como em `f(a, \..., z)` ou `a[i:\...]`.
+como em `f(a, \..., z)` ou `a[i:\\...]`.
 O NumPy usa `\...` como atalho ao fatiar arrays com muitas dimensões;
-por exemplo, se `x` é um array com quatro dimensões, `x[i, \...]` é um atalho para `x[i, :, :, :,]`.
+por exemplo, se `x` é um array com quatro dimensões, `x[i, \\...]` é um atalho para `x[i, :, :, :,]`.
 Veja  https://fpy.li/2-13["NumPy quickstart"] (EN)
 para saber mais sobre isso.
 

capitulos/cap06.adoc

@@ -329,7 +329,7 @@ quando se comparam coleções grandes ou estruturas aninhadas com muitos níveis
 ====
 Normalmente estamos mais interessados na igualdade que na identidade de objetos.
 Checar se o objeto é `None` é _o único_ caso de uso comum do operador `is`.
-A maioria dos outros usos que eu vejo quando reviso código estão errados.
+A maioria dos outros usos que vejo quando reviso código estão errados.
 Se você não estiver seguro, use `==`. Em geral, é o que você quer,
 e ele também funciona com `None`, ainda que não tão rápido.
 ====

capitulos/cap07.adoc

@@ -881,7 +881,7 @@ Lisp, entretanto, não limita o que pode ser feito dentro de uma `lambda`, pois
 Python usa uma sintaxe orientada a instruções (_statement oriented syntax_),
 na qual as expressões não podem conter instruções,
 e muitas das estruturas da linguagem são instruções--incluindo `try/catch`,
-que é o que eu mais sinto falta quando escrevo uma `lambda`.
+que é o que mais sinto falta quando escrevo uma `lambda`.
 É o preço a pagar pela sintaxe extremamente legível de Python.footnote:[Há também o problema da perda de indentação quando colamos trechos de código em fóruns na Web, mas isso é outro assunto.] Lisp tem muitas virtudes, mas legibilidade não é uma delas.
 
 Ironicamente, roubar a sintaxe de compreensão de lista de outra linguagem funcional—Haskell—reduziu significativamente a necessidade de usar `map` e `filter`, e também `lambda`.

capitulos/cap08.adoc

@@ -70,7 +70,7 @@ Exceto pela nova assinatura do construtor, me assegurei que todos os testes real
 [WARNING]
 ====
 Quando um `Vector` tem mais de seis componentes, a string produzida por `repr()` é abreviada com
-`...`, como visto na última linha do <<ex_vector_demo>>. Isso é fundamental para qualquer tipo de coleção que possa conter um número grande de itens, pois `repr` é usado na depuração—e você não quer que um único objeto grande ocupe milhares de linhas em seu console ou arquivo de log. Use o módulo `reprlib` para produzir representações de tamanho limitado, como no <<ex_vector_v1>>. O módulo `reprlib` se chamava `repr` no Python 2.7.
+`\...`, como visto na última linha do <<ex_vector_demo>>. Isso é fundamental para qualquer tipo de coleção que possa conter um número grande de itens, pois `repr` é usado na depuração—e você não quer que um único objeto grande ocupe milhares de linhas em seu console ou arquivo de log. Use o módulo `reprlib` para produzir representações de tamanho limitado, como no <<ex_vector_v1>>. O módulo `reprlib` se chamava `repr` no Python 2.7.
 ====
 
 O <<ex_vector_v1>> lista a implementação de nossa primeira versão de `Vector` (esse exemplo usa como base o código mostrado no pass:[<a data-type="xref" href="#ex_vector2d_v0" data-xrefstyle="select: labelnumber">#ex_vector2d_v0</a>] e no pass:[<a data-type="xref" href="#ex_vector2d_v1" data-xrefstyle="select: labelnumber">#ex_vector2d_v1</a>] do <<ch_pythonic_obj>>).
@@ -801,7 +801,7 @@ Um &#x5f;&#x5f;format&#x5f;&#x5f; seguro, com usabilidade aperfeiçoada
 Ao((("&#x005F;&#x005F;format&#x005F;&#x005F;")))((("Soapbox sidebars", "&#x005F;&#x005F;format&#x005F;&#x005F;", secondary-sortas="format"))) implementar `+__format__+`, não tomei qualquer precaução a respeito de instâncias de `Vector` com um número muito grande de componentes, como fizemos no `+__repr__+` usando `reprlib`. A justificativa é que `repr()` é usado para depuração e registro de logs, então precisa sempre gerar uma saída minimamente aproveitável, enquanto
 `+__format__+` é usado para exibir resultados para usuários finais, que presumivelmente desejam ver o `Vector` inteiro. Se isso for considerado inconveniente, então seria legal implementar um nova extensão à Minilinguagem de especificação de formato.
 
-O quê eu faria: por default, qualquer `Vector` formatado mostraria um número razoável mas limitado de componentes, digamos uns 30. Se existirem mais elementos que isso, o comportamento default seria similar ao de `reprlib`: cortar o excesso e colocar `...` em seu lugar. Entretanto, se o especificador de formato terminar com um código especial `+*+`, significando "all" (_todos_), então a limitação de tamanho seria desabilitada. Assim, um usuário ignorante do problema de exibição de vetores muito grandes não será acidentalmente penalizado. Mas se a limitação default se tornar incômoda, a presença das `...` iria incentivar o usuário a consultar a documentação e descobrir o código de formatação `*` .
+O quê eu faria: por default, qualquer `Vector` formatado mostraria um número razoável mas limitado de componentes, digamos uns 30. Se existirem mais elementos que isso, o comportamento default seria similar ao de `reprlib`: cortar o excesso e colocar `\...` em seu lugar. Entretanto, se o especificador de formato terminar com um código especial `+*+`, significando "all" (_todos_), então a limitação de tamanho seria desabilitada. Assim, um usuário ignorante do problema de exibição de vetores muito grandes não será acidentalmente penalizado. Mas se a limitação default se tornar incômoda, a presença das `\...` iria incentivar o usuário a consultar a documentação e descobrir o código de formatação `*` .
 
 
 [role="soapbox-title"]

capitulos/cap12.adoc

@@ -490,7 +490,7 @@ Então, a partir dessa analogia bem frouxa com as revoluções taxonômicas no m
 
 A _goose typing_ significa o seguinte: `isinstance(obj, cls)` agora é plenamente aceitável... desde que `cls` seja uma classe base abstrata - em outras palavras, a metaclasse de ++cls++ é `abc.ABCMeta`.
 
-Você vai encontrar muitas classes abstratas prontas em `collections.abc` (e outras no módulo `numbers` da _Biblioteca Padrão de Python_)footnote:[Você também pode, claro, definir suas próprias ABCs - mas eu não recomendaria esse caminho a ninguém, exceto aos mais avançados pythonistas, da mesma forma que eu os desencorajaria de definir suas próprias metaclasses customizadas... e mesmo para os ditos "mais avançados pythonistas", aqueles de nós que exibem o domínio de todos os recantos por mais obscuros da linguagem, essas não são ferramentas de uso frequente. Este tipo de "metaprogramação profunda", se alguma vez for apropriada, o será no contexto dos autores de frameworks abrangentes, projetadas para serem estendidas de forma independente por inúmeras equipes de desenvolvimento diferentes... menos que 1% dos "mais avançados pythonistas" precisará disso alguma vez na vida! - _A.M_]
+Você vai encontrar muitas classes abstratas prontas em `collections.abc` (e outras no módulo `numbers` da _Biblioteca Padrão de Python_)footnote:[Você também pode, claro, definir suas próprias ABCs - mas eu não recomendaria esse caminho a ninguém, exceto aos mais avançados pythonistas, da mesma forma que os desencorajaria de definir suas próprias metaclasses customizadas... e mesmo para os ditos "mais avançados pythonistas", aqueles de nós que exibem o domínio de todos os recantos por mais obscuros da linguagem, essas não são ferramentas de uso frequente. Este tipo de "metaprogramação profunda", se alguma vez for apropriada, o será no contexto dos autores de frameworks abrangentes, projetadas para serem estendidas de forma independente por inúmeras equipes de desenvolvimento diferentes... menos que 1% dos "mais avançados pythonistas" precisará disso alguma vez na vida! - _A.M_]
 
 Dentre as muitas vantagens conceituais das ABCs sobre classes concretas
 (e.g., Scott Meyer’s “toda classe não-final (não-folha) deveria ser abstrata”; veja o https://fpy.li/13-12[Item 33] de seu livro, _More Effective {cpp}_, Addison-Wesley), as ABCs de Python acrescentam uma grande vantagem prática: o método de classe `register`, que permite ao código do usuário final "declarar" que determinada classe é uma subclasse "virtual" de uma ABC (para este propósito, a classe registrada precisa cumprir os requerimentos de nome de métodos e assinatura da ABC e, mais importante, o contrato semântico subjacente - mas não precisa ter sido desenvolvida com qualquer conhecimento da ABC, e especificamente não precisa herdar dela!).
@@ -1122,7 +1122,7 @@ e ainda ter um classe sem qualquer relação passando uma verificação de `issu
 (ou porque ela faz o que quer que seja necessário para convencer um `+__subclasshook__+` a dar a ela seu aval).
 
 É uma boa ideia implementar `+__subclasshook__+` em nossas próprias ABCs? Provavelmente não.
-Todas as implementações de `+__subclasshook__+` que eu vi no código-fonte de Python estão em ABCs como `Sized`, que declara apenas um método especial, e elas simplesmente verificam a presença do nome daquele método especial.
+Todas as implementações de `+__subclasshook__+` que vi no código-fonte de Python estão em ABCs como `Sized`, que declara apenas um método especial, e elas simplesmente verificam a presença do nome daquele método especial.
 Dado seu status "especial", é quase certeza que qualquer método chamado `+__len__+` faz o que se espera.
 Mas mesmo no reino dos métodos especiais e ABCs fundamentais,
 pode ser arriscado fazer tais suposições.
@@ -1327,7 +1327,7 @@ então o Mypy pode inferir que dentro do bloco `if`, o tipo do objeto `o` é _co
 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,
+Continuando a discussão anterior: dado um objeto `o` que preciso usar como número complexo,
 essa seria uma abordagem:
 
 [source, python]
@@ -1967,7 +1967,7 @@ Eles está falando de interface de usuário, mas a advertência se aplica també
 Mas Cooper admite que quando uma metáfora "verdadeiramente apropriada" "cai no nosso colo," podemos usá-la (ele escreve "cai no nosso colo" porque é tão difícil encontrar metáforas adequadas que ninguém deveria perder tempo tentando encontrá-las ativamente).
 Acredito que a imagem da máquina de bingo que usei nesse capítulo é apropriada e eu a defenderei.
 
-_About Face_ é, de longe, o melhor livro sobre design de UI que eu já li - e eu li uns tantos.
+_About Face_ é, de longe, o melhor livro sobre design de UI que já li - e eu li uns tantos.
 Abandonar as metáforas como paradigmas de design, as substituindo por "interfaces idiomáticas", foi a lição mais valiosa que aprendi com o trabalho de Cooper.
 
 Em _About Face_, Cooper não lida com APIs, mas quanto mais penso em suas ideias, mais vejo como se aplicam ao Python.

capitulos/cap13.adoc

@@ -61,7 +61,7 @@ def sum(__iterable: Iterable[_T], start: _S) -> Union[_T, _S]: ...
 Primeiro, vamos olhar a sintaxe geral das sobreposições.
 Esse acima é todo o código sobre `sum` que você encontrará no arquivo stub (_.pyi_).
 A implementação estará em um arquivo diferente.
-As reticências (`...`) não tem qualquer função além de cumprir a exigência sintática para um corpo de função, como no caso de `pass`.
+As reticências (`\...`) não tem qualquer função além de cumprir a exigência sintática para um corpo de função, como no caso de `pass`.
 Assim os arquivos _.pyi_ são arquivos Python válidos.
 
 Como mencionado na <<arbitrary_arguments_sec>>, os dois sublinhados prefixando `+__iterable+` são a convenção da PEP 484 para argumentos apenas posicionais, que é verificada pelo Mypy.

capitulos/cap15.adoc

@@ -106,7 +106,7 @@ said
 ----
 ====
 <1> Uma sentença criada a partir de uma string.
-<2> Observe a saída de `+__repr__+` gerada por `reprlib.repr`, usando `...`.
+<2> Observe a saída de `+__repr__+` gerada por `reprlib.repr`, usando `\...`.
 <3> Instâncias de `Sentence` são iteráveis; veremos a razão em seguida.
 <4> Sendo iteráveis, objetos `Sentence` podem ser usados como entrada para criar listas e outros tipos iteráveis.
 
@@ -2195,7 +2195,7 @@ Essa alegre discussão sobre variância encerra o capítulo mais longo do livro.
 
 === Resumo do capítulo
 
-A iteração((("iterators", "overview of")))((("generators", "overview of")))((("coroutines", "overview of"))) está integrada tão profundamente à linguagem que eu gosto de dizer que Python _groks_ iteradoresfootnote:[De acordo com o https://fpy.li/17-26[Jargon file] (EN), _to grok_ não é meramente aprender algo, mas absorver de uma forma que "aquilo se torna parte de você, parte de sua identidade".]
+A iteração((("iterators", "overview of")))((("generators", "overview of")))((("coroutines", "overview of"))) está integrada tão profundamente à linguagem que gosto de dizer que Python _groks_ iteradoresfootnote:[De acordo com o https://fpy.li/17-26[Jargon file] (EN), _to grok_ não é meramente aprender algo, mas absorver de uma forma que "aquilo se torna parte de você, parte de sua identidade".]
 A integração do padrão _Iterator_ na semântica de Python é um exemplo perfeito de como padrões de projeto não são aplicáveis a todas as linguagens de programação.
 No Python, um _Iterator_ clássico, implementado "à mão", como no <<ex_sentence1>>, não tem qualquer função prática, exceto como exemplo didático.
 

capitulos/cap17.adoc

@@ -550,7 +550,7 @@ Resumindo, o mapeamento `env` é carregado com:
 O((("lis.py interpreter", "REPL (read-eval-print-loop)"))) REPL (read-eval-print-loop, _loop-lê-calcula-imprime_ ) de Norvig é fácil de entender mas não é amigável ao usuário (veja o <<ex_lispy_repl>>).
 Se nenhum argumento de linha de comando é passado a _lis.py_,
 a função `repl()` é invocada por `main()`—definida no final do módulo.
-No prompt de `lis.py>`, devemos digitar expressões corretas e completas; se esquecemos de fechar um só parênteses, _lis.py_ se encerra.footnote:[Enquanto estudava o _lis.py_ e o _lispy.py_ de Norvig, comecei uma versão chamada https://fpy.li/18-20[_mylis_], que acrescenta alguns recursos, incluindo um REPL que aceita expressões-S parciais e espera a continuação, como o REPL de Python sabe que não terminamos e apresenta um prompt secundário (`...`) até entrarmos uma expressão ou instrução completa, que possa ser analisada e avaliada. O _mylis_ também trata alguns erros de forma graciosa, mas ele ainda é fácil de quebrar. Não é nem de longe tão robusto quanto o REPL de Python.]
+No prompt de `lis.py>`, devemos digitar expressões corretas e completas; se esquecemos de fechar um só parênteses, _lis.py_ se encerra.footnote:[Enquanto estudava o _lis.py_ e o _lispy.py_ de Norvig, comecei uma versão chamada https://fpy.li/18-20[_mylis_], que acrescenta alguns recursos, incluindo um REPL que aceita expressões-S parciais e espera a continuação, como o REPL de Python sabe que não terminamos e apresenta um prompt secundário (`\...`) até entrarmos uma expressão ou instrução completa, que possa ser analisada e avaliada. O _mylis_ também trata alguns erros de forma graciosa, mas ele ainda é fácil de quebrar. Não é nem de longe tão robusto quanto o REPL de Python.]
 
 [role="pagebreak-before less_space"]
 [[ex_lispy_repl]]