revisão de xrefs para exemplos de outros capítulos no mesmo volume

Author: ramalho

online/cap02.adoc

@@ -367,7 +367,7 @@ estivessem aninhados na mesma ordem que eles aparecem na listcomp.
 quebrar a listcomp em duas linhas torna mais fácil ver como o resultado será ordenado.
 
 
-No <<ex_pythonic_deck>> (<<ch_data_model>>)
+No <<ex_pythonic_deck>> do <<ch_data_model>>
 usei a seguinte expressão para inicializar um baralho de cartas com uma lista
 contendo 52 cartas de todos os 13 valores possíveis para cada um dos quatro naipes,
 ordenada por naipe e então por valor:

online/cap05.adoc

@@ -432,7 +432,7 @@ Pule a próxima caixinha se você não estiver interessada em gambiarras.
 .Remendando uma tupla nomeada para injetar um método
 ****
 
-Lembre como criamos a classe `Card` class no <<ex_pythonic_deck>> (<<ch_data_model>>):
+Lembre como criamos a classe `Card` class no <<ex_pythonic_deck>> do <<ch_data_model>>:
 
 [source, python]
 ----

online/cap12.adoc

@@ -118,7 +118,7 @@ Quando um `Vector` tem mais de seis componentes, a string produzida por `repr()`
 ====
 
 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 <<ex_vector2d_v0>> e
+(este exemplo usa como base o código mostrado no <<ex_vector2d_v0>> e
 <<ex_vector2d_v1>> do <<ch_pythonic_obj>>).
 
 [[ex_vector_v1]]
@@ -212,10 +212,11 @@ protocolo de sequência no Python implica apenas no métodos `+__len__+` e
 assinatura e a semântica padrão, pode ser usada em qualquer lugar onde uma
 sequência é esperada. É irrelevante se `Spam` é uma subclasse dessa ou daquela
 outra classe; tudo o que importa é que ela fornece os métodos necessários. Vimos
-isso no <<ex_pythonic_deck>>, reproduzido aqui no <<ex_pythonic_deck_rep>>.
+isso no <<ex_pythonic_deck>> do <<ch_data_model>>,
+reproduzido no <<ex_pythonic_deck_rep>>.
 
 [[ex_pythonic_deck_rep]]
-.Código do <<ex_pythonic_deck>>, reproduzido aqui por conveniência
+.Código do <<ex_pythonic_deck>> do <<ch_data_model>>, reproduzido aqui por conveniência
 ====
 [source, python]
 ----
@@ -492,7 +493,7 @@ primeiros componentes de um vetor:
 ----
 
 No `Vector2d`, oferecemos acesso somente para leitura a `x` e `y` através do
-decorador `@property` (veja o <<ex_vector2d_v3>>). Poderíamos incluir quatro
+decorador `@property` (veja o <<ex_vector2d_v3>> do <<ch_pythonic_obj>>). Poderíamos incluir quatro
 propriedades no `Vector`, mas isso seria tedioso. O método especial
 `+__getattr__+` é uma opção melhor.
 
@@ -674,7 +675,7 @@ id="hash12")))((("&#x005F;&#x005F;eq&#x005F;&#x005F;", id="eq12"))) novamente
 implementar um método `+__hash__+`. Juntamente com o `+__eq__+` existente, isso
 tornará as instâncias de `Vector` _hashable_.
 
-O `+__hash__+` do `Vector2d` (no <<ex_vector2d_v3_hash>>) computava o _hash_ de
+O `+__hash__+` do `Vector2d` (no <<ex_vector2d_v3_hash>> do <<ch_pythonic_obj>>) computava o _hash_ de
 uma `tuple` construída com os dois componentes, `self.x` and `self.y`. Agora
 podemos estar lidando com milhares de componentes, então criar uma `tuple` pode
 ser caro demais. Em vez disso, vou aplicar sucessivamente o operador `^` (xor)

online/cap13.adoc

@@ -298,7 +298,7 @@ O `FrenchDeck` original do <<ch_data_model>> também não é subclasse de
 `+__getitem__+` e `+__len__+`. Veja o <<ex_pythonic_deck_repeat>>.
 
 [[ex_pythonic_deck_repeat]]
-.Um baralho como uma sequência de cartas, como o <<ex_pythonic_deck>>.
+.Um baralho como uma sequência de cartas, como o <<ex_pythonic_deck>> do <<ch_data_model>>.
 ====
 [source, python]
 ----
@@ -1305,7 +1305,7 @@ concretas que satisfazem a interface. Essas classes estão ilustradas na
 seguinte.
 
 A classe `BingoCage` no <<ex_tombola_bingo>> é uma variação do
-<<ex_bingo_callable>> usando um randomizador melhor. `BingoCage` implementa os
+<<ex_bingo_callable>> do <<ch_func_objects>> usando um randomizador melhor. `BingoCage` implementa os
 métodos abstratos obrigatórios `load` e `pick`.
 
 [[ex_tombola_bingo]]
@@ -1328,9 +1328,9 @@ documentação do módulo `os`].
 <4> Em vez da função `random.shuffle()` normal, usamos o método `.shuffle()` de
 nossa instância de `SystemRandom`.
 
-<5> `pick` é implementado como no <<ex_bingo_callable>>.
+<5> `pick` é implementado como no <<ex_bingo_callable>> do <<ch_func_objects>>.
 
-<6> `+__call__+` também é do <<ex_bingo_callable>>. Ele não é necessário para
+<6> `+__call__+` também é do <<ex_bingo_callable>> do <<ch_func_objects>>. Ele não é necessário para
 satisfazer a interface de `Tombola`, mas é comum que subclasses tenham mais
 métodos.
 
@@ -2020,7 +2020,7 @@ Lembra((("static protocols", "supporting", id="SPsupport13"))) da classe
 ponto flutuante, faz sentido suportar a conversão de `Vector2d` para `complex`.
 
 O <<ex_vector2d_complex_v4>> mostra a implementação do método `+__complex__+`,
-para melhorar a última versão de `Vector2d`, vista no <<ex_vector2d_v3_full>>.
+para melhorar a última versão de `Vector2d`, vista no <<ex_vector2d_v3_full>> do <<ch_pythonic_obj>>.
 Para deixar o serviço completo, podemos suportar a operação inversa, com um
 método de classe `fromcomplex`, que constrói um `Vector2d` a partir de um
 `complex`.
@@ -2038,7 +2038,7 @@ include::../code/13-protocol-abc/typing/vector2d_v4.py[tags=VECTOR2D_V4_COMPLEX]
 implementação melhor no <<ex_vector2d_complex_v5>>.
 
 Dado o código acima, e o método `+__abs__+` que o `Vector2d` já tinha em
-<<ex_vector2d_v3_full>>, temos o seguinte:
+<<ex_vector2d_v3_full>> do <<ch_pythonic_obj>>, temos o seguinte:
 
 [source, python]
 ----
@@ -2179,7 +2179,7 @@ de execução sobre o item obtido.
 
 <8> Esta linha gera uma observação no relatório do Mypy.
 
-Como vimos no <<ex_top_protocol_test>>, `reveal_type` é uma função "mágica"
+Como vimos no <<ex_top_protocol_test>> do <<ch_type_hints_def>>, `reveal_type` é uma função "mágica"
 reconhecida pelo Mypy. Por isso ela não é importada e  só conseguimos chamá-la
 de dentro de blocos `if` protegidos por `typing.TYPE_CHECKING`, que só é `True`
 aos olhos de um checador de tipos estático, mas é `False` durante a

online/cap14.adoc

@@ -370,13 +370,13 @@ Herdando de `collections.UserDict` em vez de `dict`, os problemas expostos no
 ====
 
 Como um experimento, para medir o trabalho extra necessário para criar uma
-subclasse de um tipo embutido, reescrevi a classe `StrKeyDict` do
-<<ex_strkeydict>>,
+subclasse de um tipo embutido, reescrevi a classe `StrKeyDict` 
+(<<ex_strkeydict>> do <<ch_dicts_sets>>),
 para torná-la uma subclasse de `dict` em vez de `UserDict`.
 Para fazê-la passar pelo mesmo banco de testes, tive que implementar
 `+__init__+`, `get`, e `update`, pois as versões herdadas de `dict` se recusaram
 a cooperar com os métodos sobrescritos `+__missing__+`, `+__contains__+` e
-`+__setitem__+`. A subclasse de `UserDict` no <<ex_strkeydict>>
+`+__setitem__+`. A subclasse de `UserDict` no <<ex_strkeydict>> do <<ch_dicts_sets>>
 tem 16 linhas, enquanto a subclasse experimental de `dict` acabou com 33 linhas.footnote:[Se
 você tiver curiosidade, o experimento está no arquivo
 https://fpy.li/14-7[_14-inheritance/strkeydict_dictsub.py_] do repositório
@@ -1230,7 +1230,7 @@ interferem naquele estado. Mesmo se nossos métodos cooperarem chamando `super()
 e o estado interno seja protegido através da sintaxe `__x`, restarão ainda
 inúmeras formas pelas quais sobrescrever um método pode introduzir bugs.
 
-Em <<waterfowl_essay>>, Alex Martelli cita _More Effective {cpp}_, de Scott
+No texto <<waterfowl_essay>> (<<goose_typing_sec>>), Alex Martelli cita _More Effective {cpp}_, de Scott
 Meyer, que diz: "toda classe não-final (não-folha) deveria ser abstrata". Em
 outras palavras, Meyer recomenda que subclasses deveriam ser criadas apenas a
 partir de classes abstratas.

online/cap15.adoc

@@ -840,7 +840,7 @@ implementação mais simples, produzindo strings diretamente, sem passar pelo
 seria necessário.]
 
 Aqui está outro exemplo com `cast`, desta vez para corrigir uma dica de tipo
-desatualizada na biblioteca padrão de Python. No <<ex_tcp_mojifinder_main>>, criei
+desatualizada na biblioteca padrão de Python. No <<ex_tcp_mojifinder_main>> do <<ch_async>>, criei
 um objeto `asyncio.Server`, e queria obter o endereço onde o servidor está
 ouvindo (aceitando conexões). Escrevi esta linha de código:
 
@@ -892,7 +892,7 @@ seguro.
 A leitora atenta pode ter notado que `sockets[0]` poderia gerar um `IndexError`
 se `sockets` estiver vazio.
 Entretanto, até onde entendo o `asyncio`, isso não pode acontecer no
-<<ex_tcp_mojifinder_main>>, pois no momento em que leio o atributo `sockets`, o
+<<ex_tcp_mojifinder_main>> do <<ch_async>>, pois no momento em que leio o atributo `sockets`, o
 `server` já está pronto para aceitar conexões , portanto o atributo não estará
 vazio. E, de qualquer forma, `IndexError` ocorre durante a execução. O Mypy não
 consegue localizar esse problema nem mesmo em um caso trivial como
@@ -1161,7 +1161,7 @@ Dada a instabilidade da situação atual, se você precisar ler anotações dura
 pass:[<code>in&#x200b;spect&#x200b;.get_annotations</code>] ou `typing.get_type_hints`, e faça o restante de sua base de código chamar aquela função, de forma que mudanças futuras fiquem restritas a um único local.
 
 Para demonstrar esse segundo ponto, aqui estão as primeiras linhas da classe `Checked`,
-que estudaremos no <<ex_checked_class_top>>:
+que estudaremos no <<ex_checked_class_top>> do <<ch_class_metaprog>>:
 
 [source, python]
 ----
@@ -1188,7 +1188,9 @@ As seções restantes desse capítulo cobrem tipos genéricos, começando pela f
 [[impl_generic_class_sec]]
 === Implementando uma classe genérica
 
-No((("gradual type system", "implementing generic classes", id="GTSgeneric15")))((("classes", "implementing generic classes", id="CAPgeneric15")))((("generic classes, implementing", id="genclasimp15"))) <<ex_tombola_abc>>, definimos a ABC `Tombola`: uma interface para classes que funcionam como um recipiente para sorteio de bingo. A classe `LottoBlower` do  <<ex_lotto>> é uma implementação concreta.
+No((("gradual type system", "implementing generic classes", id="GTSgeneric15")))((("classes", "implementing generic classes", id="CAPgeneric15")))((("generic classes, implementing", id="genclasimp15")))
+<<ex_tombola_abc>> do <<ch_ifaces_prot_abc>>
+definimos a ABC `Tombola`: uma interface para classes que funcionam como um recipiente para sorteio de bingo. A classe `LottoBlower` (<<ex_lotto>> do <<ch_ifaces_prot_abc>>) é uma implementação concreta.
 Vamos agora estudar uma versão genérica de `LottoBlower`, usada da forma que aparece no <<ex_generic_lotto_demo>>.
 
 
@@ -1665,7 +1667,7 @@ De acordo com o https://fpy.li/15-35[_typeshed_],
 `+int.__abs__+` devolve um `int`, o que é _consistente-com_ o parametro de tipo `float` declarado na dica de tipo `is_unit` para o argumento `v`.
 
 De forma similar, podemos escrever uma versão genérica do protocolo
-`RandomPicker`, apresentado na <<ex_randompick_protocol>>, que foi definido com
+`RandomPicker`, apresentado no <<ex_randompick_protocol>> do <<ch_ifaces_prot_abc>>, que foi definido com
 um único método `pick` devolvendo `Any`.
 
 O <<ex_generic_randompick_protocol>> mostra como criar um `RandomPicker`
@@ -1898,9 +1900,8 @@ não-documentada `TransportSocket` no módulo igualmente não documentado
 incorreto, pois esse último não é subtipo do primeiro, como explicitado em uma
 https://fpy.li/15-52[docstring] no código-fonte.
 
-
 Caí em uma toca de coelho similar quando acrescentei dicas de tipo ao
-<<ex_primes_procs_top>>, uma demonstração simples de `multiprocessing`.
+<<ex_primes_procs_top>> do <<ch_concurrency_models>>, uma demonstração simples de `multiprocessing`.
 Aquele exemplo usa objetos `SimpleQueue`,
 obtidos invocando `multiprocessing.SimpleQueue()`.
 Entretanto, não pude usar aquele nome em uma dica de tipo,

online/cap16.adoc

@@ -169,7 +169,7 @@ https://fpy.li/16-4[_Boolean indexing_] (indexação booleana).
 
 Como prometido acima, vamos implementar vários novos operadores na classe
 `Vector`, do  <<ch_seq_methods>>. O <<ex_vector_v6_unary>> mostra o método
-`+__abs__+`, que já estava no  <<ex_vector_v5>> (Capítulo 12),
+`+__abs__+`, que já estava no  <<ex_vector_v5>> do <<ch_seq_methods>>,
 e os novos métodos `+__neg__+` e `+__pos__+` para operadores unários.
 
 [[ex_vector_v6_unary]]
@@ -560,7 +560,7 @@ type(s) for +: 'Vector' and 'str'” (_tipos de operandos não suportados para +
 A implementação final dos métodos especiais de adição de `Vector` está no <<ex_vector_v6>>.
 
 [[ex_vector_v6]]
-.vector_v6.py: métodos do operador `{plus}` adicionados a vector_v5.py (no <<ex_vector_v5>>)
+.vector_v6.py: métodos do operador `{plus}` adicionados a vector_v5.py (<<ex_vector_v5>> do <<ch_seq_methods>>)
 ====
 [source, python]
 ----
@@ -897,7 +897,7 @@ herdados da classe `object` comparam os IDs dos objetos, então não ocorre `Typ
 |=================================================================================================
 
 Considerando estas regras, vamos revisar e aperfeiçoar o comportamento do método
-`+Vector.__eq__+`, escrito assim no __vector_v5.py__ (<<ex_vector_v5>>):
+`+Vector.__eq__+`, escrito assim no __vector_v5.py__ (<<ex_vector_v5>> do <<ch_seq_methods>>):
 
 [source, python]
 ----
@@ -1011,7 +1011,7 @@ vc)+`.
 
 . `+Vector2d.__eq__(v2d, vc)+` transforma os dois operandos em tuplas e os
 compara: o resultado é `True` (o código de `+Vector2d.__eq__+` está no
-<<ex_vector2d_v3_full>>).
+<<ex_vector2d_v3_full>> do <<ch_pythonic_obj>>).
 
 Já para a comparação `va == t3`, entre `Vector` e `tuple` no <<eq_demo_new_eq>>,
 os passos são:
@@ -1147,7 +1147,7 @@ exemplos.
 ====
 
 Para mostrar o código de um método interno de atribuição aumentada, vamos
-estender a classe `BingoCage` do <<ex_tombola_bingo>> para implementar
+estender a classe `BingoCage` do <<ex_tombola_bingo>> do <<ch_ifaces_prot_abc>> para implementar
 `+__add__+` e `+__iadd__+`.
 
 Vamos chamar a subclasse de `AddableBingoCage`. Os doctests da classe
@@ -1227,8 +1227,8 @@ argumento iterável.
 
 Agora que vimos o comportamento desejado para `AddableBingoCage`, podemos
 estudar sua implementação no <<ex_addable_bingo>>. Lembre-se de que `BingoCage`,
-do <<ex_tombola_bingo>>, é uma subclasse concreta da ABC `Tombola` do
-<<ch_ifaces_prot_abc>>, <<ex_tombola_abc>>.
+(<<ex_tombola_bingo>> do <<ch_ifaces_prot_abc>>), é uma subclasse concreta da ABC `Tombola` do
+<<ex_tombola_abc>> do <<ch_ifaces_prot_abc>>.
 
 [[ex_addable_bingo]]
 .bingoaddable.py: `AddableBingoCage` é subclasse de `BingoCage` com suporte aos operadores `{plus}` e `{iadd}`

online/cap17.adoc

@@ -729,7 +729,7 @@ Expressões geradoras são "açúcar sintático": elas pode sempre ser substitu
 
 === Quando usar expressões geradoras
 
-Eu((("generators", "when to use generator expressions")))((("generator expressions (genexps)"))) usei várias expressões geradoras quando implementamos a classe `Vector` no <<ex_vector_v5>>. Cada um destes métodos contém uma expressão geradora: `+__eq__+`, `+__hash__+`, `+__abs__+`, `angle`, `angles`, pass:[<span class="keep-together"><code>format</code></span>], `+__add__+`, e `+__mul__+`.
+Eu((("generators", "when to use generator expressions")))((("generator expressions (genexps)"))) usei várias expressões geradoras quando implementamos a classe `Vector` no <<ex_vector_v5>> do <<ch_seq_methods>>. Cada um destes métodos contém uma expressão geradora: `+__eq__+`, `+__hash__+`, `+__abs__+`, `angle`, `angles`, pass:[<span class="keep-together"><code>format</code></span>], `+__add__+`, e `+__mul__+`.
 //  has a generator expression.
 Em todos aqueles métodos, uma compreensão de lista também funcionaria, com um custo adicional de memória para armazenar os valores da lista intermediária.
 
@@ -743,7 +743,7 @@ Minha regra básica para escolher qual sintaxe usar é simples: se a expressão
 [TIP]
 .Dica de sintaxe
 ====
-Quando uma expressão geradora é passada como único argumento a uma função ou a um construtor, não é necessário escrever um conjunto de parênteses para a chamada da função e outro par cercando a expressão geradora. Um único par é suficiente, como na chamada a `Vector` no método `+__mul__+` do <<ex_vector_v5>>, reproduzido abaixo:
+Quando uma expressão geradora é passada como único argumento a uma função ou a um construtor, não é necessário escrever um conjunto de parênteses para a chamada da função e outro par cercando a expressão geradora. Um único par é suficiente, como na chamada a `Vector` no método `+__mul__+` do <<ex_vector_v5>> do <<ch_seq_methods>>, reproduzido abaixo:
 
 [source, python]
 ----

online/cap22.adoc

@@ -253,7 +253,9 @@ Nossa próxima tarefa é reestruturar os dados para preparar a recuperação aut
 [[computed_props_sec]]
 === Propriedades computadas
 
-Vimos inicialmente o decorador `@property` no <<ch_pythonic_obj>>, na <<hashable_vector2d_sec>>. No <<ex_vector2d_v3>>, usei duas propriedades no `Vector2d` apenas para tornar os atributos `x` e `y` apenas para leitura.
+Vimos inicialmente o decorador `@property` na <<hashable_vector2d_sec>>.
+No <<ex_vector2d_v3>> do <<ch_pythonic_obj>>,
+usei duas propriedades no `Vector2d` apenas para tornar os atributos `x` e `y` apenas para leitura.
 Aqui vamos ver propriedades que calculam valores, levando a uma discussão sobre como armazenar tais valores.
 
 Os((("computed properties", "properties that compute values")))((("dynamic attributes and properties", "computed properties", id="DAPcomputp22"))) registros na lista `'events'` dos dados JSON da OSCON contêm números de série inteiros apontando para registros nas listas `'speakers'` e `'venues'`.

online/cap24.adoc

@@ -1323,7 +1323,8 @@ Metaclasses, bem((("class metaprogramming", "useful applications of metaclasses"
 
 Em alguns casos, a metaprogramação de classes também pode ajudar em questões de desempenho, executando tarefas no momento da importação que de outra forma seriam executadas repetidamente durante a execução.
 
-Para finalizar, vamos nos lembrar do conselho final de Alex Martelli em seu ensaio <<waterfowl_essay>>:
+Para finalizar, vamos nos lembrar do conselho final de Alex Martelli em seu ensaio <<waterfowl_essay>>
+(<<goose_typing_sec>>):
 
 [quote]
 ____