vol2: xrefs simples para outros capítulos

Author: ramalho

online/cap08.adoc

@@ -1529,7 +1529,7 @@ Uma função deve ser mais precisa sobre o tipo concreto que retorna.
 
 O  tipo `Iterator`, usado como tipo do retorno no <<charindex_ex>>,
 está intimamente relacionado a `Iterable`.
-Voltaremos a ele em <<ch_generators>>, que trata de geradores e
+Voltaremos a ele no <<ch_generators>>, que trata de geradores e
 iteradores clássicos.((("", startref="GTSiterable08")))((("", startref="iterable08")))
 
 [[param_generics_typevar_sec]]

online/cap11.adoc

@@ -1275,8 +1275,8 @@ mas torna a classe mais fácil de testar.
 
 Ao expandir o código do `Vector2d` meu objetivo foi criar um contexto para a
 discussão dos métodos especiais e outras convenções de programação em Python.
-Os exemplos neste capítulo demonstraram vários dos métodos especiais vistos
-antes na <<special_names_tbl>> (<<ch_data_model>>):
+Os exemplos neste capítulo demonstraram vários dos métodos especiais mencionados
+no https://fpy.li/1[«Capítulo 1»] (vol.1):
 
 * Métodos de representação de strings e bytes: `+__repr__+`, `+__str__+`,
 `+__format__+` e `+__bytes__+`

online/cap13.adoc

@@ -997,7 +997,7 @@ facilitar a criação de subclasses de `Iterable`, `Container`, e `Sized`.
 Esses são os principais tipos de coleções imutáveis, e cada um tem uma subclasse
 mutável. Um diagrama detalhado de `MutableSequence` é apresentado na
 <<mutablesequence_uml>>; para `MutableMapping` e `MutableSet`, veja a
-<<mapping_uml>> e a <<set_uml>> em <<ch_dicts_sets>>.
+<<mapping_uml>> e a <<set_uml>> no <<ch_dicts_sets>>.
 
 `MappingView`::
 No Python 3, os objetos devolvidos pelos métodos de mapeamentos `.items()`,
@@ -1008,7 +1008,7 @@ implementam a rica interface de `Set`, com todos os operadores que vimos na
 
 `Iterator`::
 Observe que iterator é subclasse de `Iterable`.
-Discutiremos este detalhe em <<ch_generators>>.
+Discutiremos este detalhe no <<ch_generators>>.
 
 `Callable`, `Hashable`::
 Estas não são coleções, mas `collections.abc` foi o primeiro pacote a definir
@@ -1039,7 +1039,7 @@ Essa chamada vai levantar um `TypeError` se `obj` não for _hashable_.
 
 Por outro lado, mesmo quando `isinstance(obj, Iterable)` retorna `False`,
 o Python ainda pode ser capaz de iterar sobre `obj` usando `+__getitem__+`
-com índices baseados em 0, como vimos em <<ch_data_model>> e
+com índices baseados em 0, como vimos no <<ch_data_model>> e
 na <<python_digs_seq_sec>>. A documentação de
 https://fpy.li/6q[`collections.abc.Iterable`]
 afirma:

print/xrefs/xref-other-vols.ipynb

@@ -83,15 +83,15 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 18,
+   "execution_count": 21,
    "id": "546fd140-6977-469a-8e32-c7497f09dc27",
    "metadata": {},
    "outputs": [],
    "source": [
     "# duas xrefs:\n",
     "# A maior parte do <<ch_type_hints_def>> e do <<ch_more_types>>\n",
     "\n",
-    "for cap_n in range(13, 14):\n",
+    "for cap_n in range(9, 17):\n",
     "    with open(path_adoc(cap_n)) as fp:\n",
     "        adoc = fp.read()\n",
     "    for ident, (vol, cap) in other_vols.items():\n",
@@ -109,6 +109,14 @@
    "metadata": {},
    "outputs": [],
    "source": []
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "id": "552c2fa0-ff72-404b-a7b1-868273c38cb9",
+   "metadata": {},
+   "outputs": [],
+   "source": []
   }
  ],
  "metadata": {

vol2/cap09.adoc

@@ -91,7 +91,7 @@ Um decorador pode executar algum processamento com a função decorada, e pode
 devolver a mesma função ou substituí-la por outra função ou objeto invocável.footnote:[Se
 você substituir "função" por "classe" na sentença anterior, o resultado é uma
 descrição resumida do papel de um decorador de classe, assunto que veremos no
-<<ch_class_metaprog>>.]
+https://fpy.li/24[«Capítulo 24»] (vol.3).]
 
 Em outras palavras, supondo a existência de uma função decoradora
 chamada `decorate`, este código:
@@ -1525,7 +1525,7 @@ decorada com `clocked`.
 <4> `clocked` envolve a função decorada.
 
 Isso encerra nossa exploração dos decoradores de função. Veremos os decoradores
-de classe no <<ch_class_metaprog>>.((("", startref="DACparam09")))((("",
+de classe no https://fpy.li/24[«Capítulo 24»] (vol.3).((("", startref="DACparam09")))((("",
 startref="paramdec09")))
 
 
@@ -1580,7 +1580,7 @@ no módulo https://fpy.li/9-7[`wrapt`], que ele escreveu para simplificar a
 implementação de decoradores e invólucros (_wrappers_) dinâmicos de função,
 que suportam introspecção e se comportam de forma correta quando decorados
 novamente, quando aplicados a métodos e quando usados como descritores de
-atributos (o <<ch_descriptors>> é sobre descritores).
+atributos (o https://fpy.li/23[«Capítulo 23»] (vol.3) é sobre descritores).
 
 https://fpy.li/9-8["Metaprogramming" (_Metaprogramação_)] (EN), o capítulo 9 do
 _Python Cookbook_, 3ª ed. de David Beazley e Brian K. Jones (O'Reilly), tem

vol2/cap10.adoc

@@ -30,7 +30,7 @@ também em outras linguagens orientadas a objetos.
 
 Apesar dos padrões de projeto serem independentes da linguagem, isso não
 significa que todo padrão se aplica a todas as linguagens. Por exemplo, o
-<<ch_generators>> vai mostrar que não faz sentido implementr a receita do padrão
+https://fpy.li/17[«Capítulo 17»] (vol.3) vai mostrar que não faz sentido implementr a receita do padrão
 https://fpy.li/10-2[Iterador (_Iterator_)] em Python, pois esse padrão está
 embutido na linguagem e pronto para ser usado, na forma de geradores—que não
 precisam de classes para funcionar, e exigem menos código que a receita

vol2/cap11.adoc

@@ -26,7 +26,7 @@ usarão suas classes talvez esperem que elas se comportem como as classes
 fornecidas pelo Python. Satisfazer tal expectativa é um dos jeitos de ser
 "pythônico".
 
-Esse capítulo começa onde o <<ch_data_model>> terminou, mostrando como
+Esse capítulo começa onde o https://fpy.li/1[«Capítulo 1»] (vol.1) terminou, mostrando como
 implementar vários métodos especiais comumente vistos em objetos Python de
 diferentes tipos.
 
@@ -85,7 +85,7 @@ string representando o objeto de uma forma amigável para o usuário final.
 
 Os((("&#x005F;&#x005F;repr&#x005F;&#x005F;")))((("&#x005F;&#x005F;str&#x005F;&#x005F;")))
 métodos especiais `+__repr__+` e `+__str__+` suportam `repr()` e `str()`, como
-vimos no <<ch_data_model>>.
+vimos no https://fpy.li/1[«Capítulo 1»] (vol.1).
 
 Existem((("&#x005F;&#x005F;bytes&#x005F;&#x005F;")))((("&#x005F;&#x005F;format&#x005F;&#x005F;")))
 mais dois métodos especiais para gerar representações alternativas de
@@ -112,7 +112,7 @@ Se você está vindo de Python 2, lembre-se que no Python 3
 Para((("Pythonic objects", "Vector2d class example",
 id="PYvector11")))((("Vector2d", "class example", id="V2dclass11"))) demonstrar
 os vários métodos usados para gerar representações de objetos, vamos criar uma
-classe `Vector2d`, similar à que vimos no <<ch_data_model>>. O
+classe `Vector2d`, similar à que vimos no https://fpy.li/1[«Capítulo 1»] (vol.1). O
 <<ex_vector2d_v0_demo>> ilustra o comportamento básico que esperamos de uma
 instância de `Vector2d`.
 
@@ -166,7 +166,7 @@ funcionar (por exemplo, `x, y = my_vector`). Usamos uma
 expressão geradora para produzir os dois componentes, um após outro.footnote:[Essa
 linha também poderia ser escrita assim: `yield self.x; yield.self.y`. Terei mais
 a dizer sobre o método especial `+__iter__+`, sobre expressões geradoras e sobre
-a palavra reservada `yield` no <<ch_generators>>.]
+a palavra reservada `yield` no https://fpy.li/17[«Capítulo 17»] (vol.3).]
 
 <4> O `+__repr__+` cria uma string interpolando os componentes com `{!r}`, para
 obter seus `repr`; como `Vector2d` é iterável, `*self` alimenta `format` com os
@@ -629,7 +629,7 @@ código da classe.
 ====
 
 `Vector.x` e `Vector.y` são exemplos de propriedades apenas para leitura.
-Propriedades para leitura/escrita serão tratadas no <<ch_dynamic_attrs>>, onde
+Propriedades para leitura/escrita serão tratadas no https://fpy.li/22[«Capítulo 22»] (vol.3), onde
 mergulhamos mais fundo no decorador `@property`.
 
 ====
@@ -1275,8 +1275,8 @@ mas torna a classe mais fácil de testar.
 
 Ao expandir o código do `Vector2d` meu objetivo foi criar um contexto para a
 discussão dos métodos especiais e outras convenções de programação em Python.
-Os exemplos neste capítulo demonstraram vários dos métodos especiais vistos
-antes na <<special_names_tbl>> (<<ch_data_model>>):
+Os exemplos neste capítulo demonstraram vários dos métodos especiais mencionados
+no https://fpy.li/1[«Capítulo 1»] (vol.1):
 
 * Métodos de representação de strings e bytes: `+__repr__+`, `+__str__+`,
 `+__format__+` e `+__bytes__+`
@@ -1334,7 +1334,7 @@ ____
 
 Este((("Pythonic objects", "further reading on"))) capítulo tratou de vários dos
 métodos especiais do modelo de dados, então naturalmente as referências
-primárias são as mesmas do <<ch_data_model>>, onde tivemos uma ideia geral do
+primárias são as mesmas do https://fpy.li/1[«Capítulo 1»] (vol.1), onde tivemos uma ideia geral do
 mesmo tópico. Por conveniência, vou repetir aquelas quatro recomendações
 anteriores aqui, e acrescentar algumas outras:
 
@@ -1368,7 +1368,7 @@ classes*, liberando você do tedioso trabalho de implementar protocolos de objet
 ____
 
 Mencionei `attrs` como uma alternativa mais poderosa ao `@dataclass` na
-<<dataclass_further_sec>>. As fábricas de classes de dados do <<ch_dataclass>>,
+<<dataclass_further_sec>>. As fábricas de classes de dados do https://fpy.li/5[«Capítulo 5»] (vol.1),
 assim como `attrs`, automaticamente equipam suas classes com vários métodos
 especiais. Mas saber como programar métodos especiais ainda é essencial para
 entender o que aqueles pacotes fazem, para decidir se você realmente precisa

vol2/cap12.adoc

@@ -134,7 +134,7 @@ include::../code/12-seq-hacking/vector_v1.py[tags=VECTOR_V1]
 com os componentes do `Vector`.
 
 <2> Para permitir iteração, devolvemos um itereador sobre
-`self._components`; a função `iter()` é assunto do <<ch_generators>>,
+`self._components`; a função `iter()` é assunto do https://fpy.li/17[«Capítulo 17»] (vol.3),
 juntamente com o método `+__iter__+`.
 
 <3> Usa `reprlib.repr()` para obter um representação de tamanho limitado de
@@ -1069,7 +1069,7 @@ sobre a magnitude e as coordenadas angulares.
 Usamos intensivamente expressões geradoras em `+__format__+`, `angle`, e
 `angles`, mas nosso foco aqui é fornecer um `+__format__+` para levar `Vector`
 ao mesmo nível de implementação de `Vector2d`. Quando tratarmos de geradores, no
-<<ch_generators>>, vamos usar parte do código de `Vector` nos exemplos, e lá
+https://fpy.li/17[«Capítulo 17»] (vol.3), vamos usar parte do código de `Vector` nos exemplos, e lá
 o funcionamento dos geradores será explicado em detalhes.
 ====
 
@@ -1121,7 +1121,7 @@ O último aperfeiçoamento a `Vector` foi reimplementar o método `+__format__+`
 `Vector2d`, para suportar coordenadas esféricas como alternativa às coordenadas
 cartesianas default. Usamos alguma matemática e vários geradores para
 programar `+__format__+` e suas funções auxiliares, mas esses são detalhes de
-implementação. Voltaremos aos geradores no <<ch_generators>>. O objetivo
+implementação. Voltaremos aos geradores no https://fpy.li/17[«Capítulo 17»] (vol.3). O objetivo
 daquela última seção foi suportar um formato customizado, cumprindo assim a
 promessa de um `Vector` capaz de fazer tudo que um `Vector2d` faz, e algo mais.
 

vol2/cap13.adoc

@@ -14,7 +14,7 @@ A programação orientada a objetos((("interfaces", "role in object-oriented pro
 tem tudo a ver com interfaces.
 A melhor forma de entender um tipo em Python é conhecer os métodos que
 aquele tipo oferece—sua interface—como vimos na
-<<types_defined_by_ops_sec>> (<<ch_type_hints_def>>).
+<<types_defined_by_ops_sec>> (https://fpy.li/8[«Capítulo 8»] (vol.1)).
 Desde o Python 3.8, temos quatro maneiras de definir e usar interfaces.
 Elas estão ilustradas no _Mapa de Sistemas de Tipagem_ (<<type_systems_described>>).
 
@@ -38,13 +38,13 @@ Tipagem estática::
     e aplicada por checadores de tipos externos compatíveis com a
     https://fpy.li/pep484[PEP 484—Type Hints].
     Este não é o foco deste capítulo.
-    A maior parte do <<ch_type_hints_def>> e do <<ch_more_types>>
+    A maior parte do https://fpy.li/8[«Capítulo 8»] (vol.1) e do <<ch_more_types>>
     mais adiante são sobre tipagem estática.
 Tipagem pato estática (_static duck typing_)::
     Uma((("static duck typing"))) abordagem popularizada pela linguagem Go;
     suportada por subclasses de `typing.Protocol`—lançada no Python 3.8 e também
     aplicada com o suporte de checadores de tipos externos. Tratamos desse tema
-    pela primeira vez em <<protocols_in_fn_sec>> (<<ch_type_hints_def>>), e
+    pela primeira vez em <<protocols_in_fn_sec>> (https://fpy.li/8[«Capítulo 8»] (vol.1)), e
     continuamos neste capítulo.
 
 
@@ -104,7 +104,7 @@ edição, mas foi atualizada e agora tem um título de seção que enfatiza sua
 importância.
 
 * A <<static_protocols_sec>> é toda nova. Ela se apoia na apresentação inicial na
-<<protocols_in_fn_sec>> (<<ch_type_hints_def>>).
+<<protocols_in_fn_sec>> (https://fpy.li/8[«Capítulo 8»] (vol.1)).
 
 * Os diagramas de classe de `collections.abc` neste capítulo foram atualizados
 para incluir a `Collection` ABC, do Python 3.6.
@@ -129,7 +129,7 @@ servidor, como `GET`, `PUT` e `HEAD`.
 Vimos na <<protocol_duck_sec>> que um protocolo especifica métodos
 que um objeto precisa oferecer para cumprir um papel.
 
-O exemplo `FrenchDeck` no <<ch_data_model>> demonstra um protocolo, o
+O exemplo `FrenchDeck` no https://fpy.li/1[«Capítulo 1»] (vol.1) demonstra um protocolo, o
 protocolo de sequência: os métodos que permitem a um objeto Python se comportar
 como uma sequência.
 
@@ -197,7 +197,7 @@ Agora, com a adoção da
 https://fpy.li/pep544[_PEP 544—Protocols: Structural subtyping (static duck typing)_]
 no Python 3.8, a palavra "protocolo" ganhou um novo sentido em Python—um sentido próximo,
 mas diferente.
-Como vimos na <<protocols_in_fn_sec>> (<<ch_type_hints_def>>),
+Como vimos na <<protocols_in_fn_sec>> (https://fpy.li/8[«Capítulo 8»] (vol.1)),
 a PEP 544 nos permite criar subclasses de `typing.Protocol` para definir
 um ou mais métodos que uma classe
 deve implementar (ou herdar) para satisfazer um checador de tipos estático.
@@ -293,7 +293,7 @@ Em resumo, dada a importância das sequências como estruturas de dados, Python
 fazer a iteração e o operador `in` funcionarem invocando `+__getitem__+` quando
 `+__iter__+` e `+__contains__+` não estão presentes.
 
-O `FrenchDeck` original do <<ch_data_model>> também não é subclasse de
+O `FrenchDeck` original do https://fpy.li/1[«Capítulo 1»] (vol.1) também não é subclasse de
 `abc.Sequence`, mas ele implementa os dois métodos do protocolo de sequência:
 `+__getitem__+` e `+__len__+`. Veja o <<ex_pythonic_deck_repeat>>.
 
@@ -306,7 +306,7 @@ include::../code/01-data-model/frenchdeck.py[]
 ----
 ====
 
-Muitos dos exemplos no <<ch_data_model>> funcionam por causa do tratamento
+Muitos dos exemplos no https://fpy.li/1[«Capítulo 1»] (vol.1) funcionam por causa do tratamento
 especial que Python dá a estruturas vagamente semelhantes a uma sequência.
 O protocolo iterável em Python representa uma forma extrema de tipagem pato:
 o interpretador tenta dois métodos diferentes para iterar sobre objetos.
@@ -997,7 +997,7 @@ facilitar a criação de subclasses de `Iterable`, `Container`, e `Sized`.
 Esses são os principais tipos de coleções imutáveis, e cada um tem uma subclasse
 mutável. Um diagrama detalhado de `MutableSequence` é apresentado na
 <<mutablesequence_uml>>; para `MutableMapping` e `MutableSet`, veja a
-<<mapping_uml>> e a <<set_uml>> em <<ch_dicts_sets>>.
+<<mapping_uml>> e a <<set_uml>> em https://fpy.li/3[«Capítulo 3»] (vol.1).
 
 `MappingView`::
 No Python 3, os objetos devolvidos pelos métodos de mapeamentos `.items()`,
@@ -1008,7 +1008,7 @@ implementam a rica interface de `Set`, com todos os operadores que vimos na
 
 `Iterator`::
 Observe que iterator é subclasse de `Iterable`.
-Discutiremos este detalhe em <<ch_generators>>.
+Discutiremos este detalhe em https://fpy.li/17[«Capítulo 17»] (vol.3).
 
 `Callable`, `Hashable`::
 Estas não são coleções, mas `collections.abc` foi o primeiro pacote a definir
@@ -1039,7 +1039,7 @@ Essa chamada vai levantar um `TypeError` se `obj` não for _hashable_.
 
 Por outro lado, mesmo quando `isinstance(obj, Iterable)` retorna `False`,
 o Python ainda pode ser capaz de iterar sobre `obj` usando `+__getitem__+`
-com índices baseados em 0, como vimos em <<ch_data_model>> e
+com índices baseados em 0, como vimos em https://fpy.li/1[«Capítulo 1»] (vol.1) e
 na <<python_digs_seq_sec>>. A documentação de
 https://fpy.li/6q[`collections.abc.Iterable`]
 afirma:
@@ -1380,7 +1380,7 @@ E mesmo quando recebemos uma lista no argumento `iterable`,
 considerando que vamos remover itens da lista,
 e o cliente pode não estar esperando
 que a lista passada seja modificada.footnote:[<<defensive_argument>>
-(<<ch_refs_mut_mem>>) trata do problema de apelidamento
+(https://fpy.li/6[«Capítulo 6»] (vol.1)) trata do problema de apelidamento
 que acabamos de evitar aqui.]
 
 Chegamos agora à característica dinâmica da tipagem ganso:
@@ -2482,7 +2482,7 @@ reconhecimento de classes não-relacionadas, mas que fornecem os métodos
 exigidos pela interface declarada na ABC.
 
 Retomamos o estudo da tipagem pato estática na <<static_protocols_sec>>, que
-havia começado no <<ch_type_hints_def>>, em <<protocols_in_fn_sec>>. Vimos como
+havia começado no https://fpy.li/8[«Capítulo 8»] (vol.1), em <<protocols_in_fn_sec>>. Vimos como
 o decorador `@runtime_checkable` também aproveita o `+__subclasshook__+` para
 suportar tipagem estrutural durante a execução—mesmo que o melhor uso dos
 protocolos estáticos seja com checadores de tipos estáticos, que podem levar em
@@ -2556,7 +2556,7 @@ O _Python Cookbook_, 3rd ed. de Beazley & Jones (O'Reilly) tem uma seção sobre
 como definir uma ABC (Recipe 8.12). O livro foi escrito antes de Python 3.4,
 então eles não usam a atual sintaxe preferida para declarar ABCs, criar uma
 subclasse de `abc.ABC` (em vez disso, eles usam a palavra-chave `metaclass`, da
-qual só vamos precisar mesmo no <<ch_class_metaprog>>). Tirando esse pequeno
+qual só vamos precisar mesmo no https://fpy.li/24[«Capítulo 24»] (vol.3)). Tirando esse pequeno
 detalhe, a receita cobre os principais recursos das ABCs muito bem.
 
 _The Python Standard Library by Example_ de Doug Hellmann (Addison-Wesley), tem

vol2/cap14.adoc

@@ -371,12 +371,12 @@ 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>> (<<ch_dicts_sets>>),
+<<ex_strkeydict>> (https://fpy.li/3[«Capítulo 3»] (vol.1)),
 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>> do <<ch_dicts_sets>>
+`+__setitem__+`. A subclasse de `UserDict` no <<ex_strkeydict>> do https://fpy.li/3[«Capítulo 3»] (vol.1)
 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
@@ -1413,7 +1413,7 @@ Knight. A resposta de Martijn Pieters a
 https://fpy.li/14-41[_How to use super() with one argument?_]
 (Como usar super() com um só argumento?)
 inclui uma explicação concisa e aprofundada de `super`, incluindo sua relação
-com descritores, um conceito que estudaremos apenas no <<ch_descriptors>>. 
+com descritores, um conceito que estudaremos apenas no https://fpy.li/23[«Capítulo 23»] (vol.3). 
 Assim é `super`: simples de usar nos casos básicos, mas também
 uma ferramenta poderosa e complexa, que alcança alguns dos recursos dinâmicos
 mais avançados de Python, raramente encontrados em outras linguagens.