xrefs wip

Author: ramalho

online/Prefacio.adoc

@@ -94,7 +94,7 @@ Acredito que isso é mais fácil de tolerar agora que você sabe porque escolhi
 Aqui estão os principais tópicos de cada parte do livro:
 
 <<data_structures_part>>::
-O <<ch_data_model>> introduz o Modelo de Dados de Python e explica porque os métodos especiais (por exemplo, `+__repr__+`) são a chave do comportamento consistente de objetos de todos os tipos. Os métodos especiais são tratados em maiores detalhes ao longo do livro. Os((("data structures"))) capítulos restantes dessa parte cobrem o uso de tipos coleção: sequências, mapeamentos e conjuntos, bem como a separação de `str` e `bytes`--causa de muitas celebrações entre usuários de Python 3, e de muita dor para usuários de Python 2 obrigados a migrar suas bases de código. Também são abordadas as fábricas de classe de alto nível na biblioteca padrão: fábricas de tuplas nomeadas e o decorador `@dataclass`. _Pattern matching_ ("casamento de padrões")—novidade no Python 3.10—é tratada em seções do <<ch_sequences>>,
+O <<ch_data_model>> introduz o Modelo de Dados de Python e explica porque os métodos especiais (por exemplo, `+__repr__+`) são a chave do comportamento consistente de objetos de todos os tipos. Os métodos especiais são tratados em mais detalhes ao longo do livro. Os((("data structures"))) capítulos restantes dessa parte cobrem o uso de tipos coleção: sequências, mapeamentos e conjuntos, bem como a separação de `str` e `bytes`--causa de muitas celebrações entre usuários de Python 3, e de muita dor para usuários de Python 2 obrigados a migrar suas bases de código. Também são abordadas as fábricas de classe de alto nível na biblioteca padrão: fábricas de tuplas nomeadas e o decorador `@dataclass`. _Pattern matching_ ("casamento de padrões")—novidade no Python 3.10—é tratada em seções do <<ch_sequences>>,
 do <<ch_dicts_sets>> e
 do <<ch_dataclass>>,
 que discutem padrões para sequências, padrões para mapeamentos e padrões para instâncias de classes.

online/cap01.adoc

@@ -365,7 +365,6 @@ Geralmente, se você precisa invocar um método especial,
 é melhor chamar a função embutida relacionada (por exemplo, `len`, `iter`, `str`, etc.).
 Essas funções chamam o método especial correspondente,
 mas também fornecem outros serviços e—para tipos embutidos—são mais rápidas que chamadas a métodos.
-Veja, por exemplo, <<iter_closer_look_sec>> no <<ch_generators>>.
 
 Na próxima seção veremos alguns dos usos mais importantes dos métodos especiais:
 

online/cap02.adoc

@@ -55,7 +55,7 @@ sequências, contrastando contêineres e sequências planas.
 
 * Ressalvas sobre tuplas com elementos mutáveis, e como detectá-los se necessário.
 
-Movi a discussão sobre tuplas nomeadas para a <<classic_named_tuples_sec>> no <<ch_dataclass>>,
+Movi a discussão sobre tuplas nomeadas para a <<classic_named_tuples_sec>> (<<ch_dataclass>>),
 onde elas são comparadas com `typing.NamedTuple` e `@dataclass`.
 
 [NOTE]
@@ -365,7 +365,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>> (em <<ch_data_model>>)
+No <<ex_pythonic_deck>> (<<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/cap03.adoc

@@ -1370,7 +1370,7 @@ então Python pode mover e redimensionar a tabela conforme ela cresce.
 Quando isso acontece, os elementos são reinseridos e sua ordem relativa pode mudar.
 
 Veja o post https://fpy.li/hashint["Internals of sets and dicts"] (EN)
-no _http://fluentpython.com_ para maiores detalhes.
+no _http://fluentpython.com_ para mais detalhes.
 
 Agora vamos revisar a vasta seleção de operações oferecidas pelos conjuntos.
 

online/cap05.adoc

@@ -39,7 +39,7 @@ Entretanto, `TypedDict` não cria classes concretas que possam ser instanciadas.
 Ela é apenas a sintaxe para escrever dicas de tipo para parâmetros de função e
 variáveis que aceitarão valores de mapeamentos como registros,
 enquanto suas chaves serão os nomes dos campos.
-Veremos mais sobre isso na <<typeddict_sec>> do <<ch_more_types>>.
+Veremos mais sobre isso na <<typeddict_sec>> (<<ch_more_types>>).
 ====
 
 
@@ -430,7 +430,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>> do <<ch_data_model>>:
+Lembre como criamos a classe `Card` class no <<ex_pythonic_deck>> (<<ch_data_model>>):
 
 [source, py3]
 ----
@@ -934,7 +934,7 @@ Valores default mutáveis são a fonte mais comum de bugs entre desenvolvedores
 Em definições de função, um valor default mutável é facilmente corrompido,
 quando uma invocação da função modifica o default,
 mudando o comportamento nas invocações posteriores—um tópico que
-vamos explorar na <<mutable_default_parameter_sec>> (no <<ch_refs_mut_mem>>).
+vamos explorar na <<mutable_default_parameter_sec>> (<<ch_refs_mut_mem>>).
 Atributos de classe são frequentemente usados como valores default de atributos para instâncias,
 inclusive em classes de dados.
 E o `@dataclass` usa os valores default nas dicas de tipo para gerar parâmetros com defaults no

online/cap08.adoc

@@ -509,7 +509,7 @@ Isso é mais flexível que a _tipagem nominal_,
 ao preço de permitir mais erros durante a execução.footnote:[Duck typing é uma forma implícita de
 _tipagem estrutural_, que as anotações de tipo passaram a suportar explicitamente após a versão 3.8,
 com a introdução de `typing.Protocol`.
-Vamos falar disso mais adiante nesse capítulo, em <<protocols_in_fn>>, e com mais detalhes no <<ch_ifaces_prot_abc>>.]
+Vamos falar disso mais adiante nesse capítulo, em <<protocols_in_fn_sec>>, e com mais detalhes no <<ch_ifaces_prot_abc>>.]
 
 
 Tipagem nominal::
@@ -697,7 +697,7 @@ Nessa seção exploramos as relações de tipos e operações no duck typing e n
 começando com a função simples `double()` — que deixamos sem dicas de tipo.
 Agora vamos dar uma olhada nos tipos mais importantes ao anotar funções.
 
-Vamos ver um bom modo de adicionar dicas de tipo a `double()` quando examinarmos <<protocols_in_fn>>.
+Vamos ver um bom modo de adicionar dicas de tipo a `double()` quando examinarmos <<protocols_in_fn_sec>>.
 Mas antes disso, há tipos mais importantes para conhecer.((("", startref="FTHsupport08")))((("", startref="THsup08")))
 
 
@@ -1429,7 +1429,7 @@ Na prática, se você quiser anotar argumentos numéricos para checagem estátic
 . Declarar um tipo union como `Union[float, Decimal, Fraction]`.
 . Se você quiser evitar a codificação explícita de tipos concretos, usar protocolos numéricos como `SupportsFloat`, tratados na <<runtime_checkable_proto_sec>>.
 
-A <<protocols_in_fn>> abaixo é um pré-requisito para entender protocolos numéricos.
+A <<protocols_in_fn_sec>> abaixo é um pré-requisito para entender protocolos numéricos.
 
 Antes disso, vamos examinar uma ABC muito útil em dicas de tipo: `Iterable`.((("", startref="GTSabstract08")))((("", startref="ABChint08")))
 
@@ -1743,7 +1743,7 @@ Agora vamos ver `typing.Protocol`, um novo recurso de Python 3.8,
 que permite um uso mais pythônico de dicas de
 tipo.((("", startref="GTSparam08")))((("", startref="GCtypvar08")))((("", startref="typevar08")))
 
-[[protocols_in_fn]]
+[[protocols_in_fn_sec]]
 ==== Protocolos estáticos
 
 [NOTE]
@@ -2064,7 +2064,7 @@ Apesar de `int` ser _subtipo-de_ `float`, no `Callable` parametrizado a relaçã
 `Callable[[float], None]` é _subtipo-de_ `Callable[[int], None]`.
 Assim dizemos que aquele `Callable` é _contravariante_ a respeito dos tipos de parâmetros declarados.
 
-A <<variance_sec>> no <<ch_more_types>> explica variância em mais detalhes e
+A <<variance_sec>> (<<ch_more_types>>) explica variância em mais detalhes e
 com exemplos de tipos invariantes, covariantes e contravariantes.
 
 [TIP]

online/cap09.adoc

@@ -192,7 +192,7 @@ Decoradores parecidos são usados por muitos frameworks Python para adicionar fu
 um registro mapeando padrões de URLs para funções que geram respostas HTTP.
 Tais decoradores de registro podem ou não modificar as funções decoradas.
 
-Vamos ver um decorador de registro em ação na <<decorated_strategy>> (do <<ch_design_patterns>>).
+Vamos ver um decorador de registro em ação na <<decorated_strategy>> (<<ch_design_patterns>>).
 
 A maioria dos decoradores modificam a função decorada.
 Eles normalmente fazem isso definindo e devolvendo uma função interna para substituir a função decorada.

online/cap11.adoc

@@ -842,7 +842,7 @@ Se o código for parte de uma biblioteca para uso por outros programadores, ent
 Por exemplo, `+__eq__+` pode não ser necessário para suportar um requisito do negócio, mas torna a classe mais fácil de testar.
 
 Minha meta, ao expandir o código do `Vector2d`, foi criar um contexto para a discussão dos métodos especiais e das 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>> (do <<ch_data_model>>):
+Os exemplos neste capítulo demonstraram vários dos métodos especiais vistos antes na <<special_names_tbl>> (<<ch_data_model>>):
 
 * Métodos de representação de strings e bytes: `+__repr__+`, `+__str__+`, `+__format__+` e `+__bytes__+`
 * Métodos para reduzir um objeto a um número: `+__abs__+`, `+__bool__+` e `+__hash__+`

online/cap12.adoc

@@ -135,10 +135,10 @@ Como protocolos são informais e não obrigatórios, muitas vezes é possível r
 ====
 Com a https://fpy.li/pep544[PEP 544—Protocols: Structural subtyping (static duck typing) (_Protocolos:sub-tipagem estrutural (duck typing estático)_)] (EN),
 o Python((("protocol classes")))((("protocols", "static protocols"))) 3.8 suporta _classes protocolo_: subclasses de `typing.Protocol`,
-que estudamos na <<protocols_in_fn>>.
+que estudamos na <<protocols_in_fn_sec>>.
 Esse novo uso da palavra protocolo no Python tem um significado relacionado, mas diferente. Quando preciso diferenciá-los, escrevo((("static protocols", "versus dynamic protocols", secondary-sortas="dynamic protocols"))) _protocolo estático_ para me referir aos protocolos formalizados em classes protocolo (subclasses de `typing.Protocol`), e((("dynamic protocols"))) _protocolos dinâmicos_ para o sentido tradicional.
 Uma diferença fundamental é que implementações de um protocolo estático precisam oferecer todos os métodos definidos na classe protocolo.
-A <<two_kinds_protocols_sec>> no <<ch_ifaces_prot_abc>> traz maiores detalhes.
+A <<two_kinds_protocols_sec>> (<<ch_ifaces_prot_abc>>) traz mais detalhes.
 ====
 
 ////

online/cap13.adoc

@@ -15,8 +15,8 @@
 A programação orientada a objetos((("interfaces", "role in object-oriented programming")))
 tem tudo a ver com interfaces.
 A melhor abordagem para entender um tipo em Python é conhecer os métodos que
-aquele tipo oferece—sua interface—como discutimos na
-<<types_defined_by_ops_sec>> do (<<ch_type_hints_def>>).
+aquele tipo oferece—sua interface—como vimos na
+<<types_defined_by_ops_sec>> (<<ch_type_hints_def>>).
 
 Dependendo ((("interfaces", "ways of defining and using"))) da linguagem de programação,
 temos uma ou mais maneiras de definir e usar interfaces.
@@ -44,7 +44,7 @@ Duck typing estática::
     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>> (<<ch_type_hints_def>>),
+    Tratamos desse tema pela primeira vez em <<protocols_in_fn_sec>> (<<ch_type_hints_def>>),
     e continuamos nesse capítulo.
 
 
@@ -78,7 +78,7 @@ Este((("interfaces", "significant changes to")))((("protocols", "significant cha
 * A introdução do capítulo e o Mapa de Sistemas de Tipagem (<<type_systems_described>>) são novos. Essa é a chave da maior parte do conteúdo novo - e de todos os outros capítulos relacionados à tipagem em Python ≥ 3.8.
 * <<two_kinds_protocols_sec>> explica as semelhanças e diferenças entre protocolos dinâmicos e estáticos.
 * <<defensive_duck_prog_sec>> praticamente reproduz o conteúdo da primeira edição, mas foi atualizada e agora tem um título de seção que enfatiza sua importância.
-* <<static_protocols_sec>> é toda nova. Ela se apoia na apresentação inicial em <<protocols_in_fn>> (<<ch_type_hints_def>>).
+* <<static_protocols_sec>> é toda nova. Ela se apoia na apresentação inicial em <<protocols_in_fn_sec>> (<<ch_type_hints_def>>).
 * Os diagramas de classe de `collections.abc` nas Figuras pass:[<a href="#sequence_uml_repeat" data-type="xref" data-xrefstyle="select:labelnumber">#sequence_uml_repeat</a>], pass:[<a href="#mutablesequence_uml" data-type="xref" data-xrefstyle="select:labelnumber">#mutablesequence_uml</a>], and pass:[<a href="#collections_uml" data-type="xref" data-xrefstyle="select:labelnumber">#collections_uml</a>] foram atualizados para incluir a `Collection` ABC, de Python 3.6.
 
 A primeira edição de _Python Fluente_ tinha uma seção encorajando o uso das ABCs  `numbers` para goose typing.
@@ -145,7 +145,7 @@ Também é assim que protocolos são entendidos em Smalltalk, o primeiro ambient
 Exceto em páginas sobre programação de redes, a maioria dos usos da palavra "protocolo" na documentação de Python se refere a essas interfaces informais.
 
 Agora, com a adoção da https://fpy.li/pep544[PEP 544—Protocols: Structural subtyping (static duck typing)] (EN) 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>> (<<ch_type_hints_def>>), 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 verificador de tipo estático.
+Como vimos na <<protocols_in_fn_sec>> (<<ch_type_hints_def>>), 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 verificador de tipo estático.
 
 Quando precisar ser específico, vou adotar os seguintes termos:
 
@@ -946,7 +946,11 @@ em `+__init__+`, `self._balls` armazena `list(iterable)`, e não apenas uma refe
 Como mencionado na <<defensive_duck_prog_sec>>, isso torna nossa `LottoBlower` flexível, pois o argumento `iterable` pode ser de qualquer tipo iterável.
 Ao mesmo tempo, garantimos que os itens serão armazenados em uma `list`, da onde podemos `pop` os itens.
 E mesmo se nós sempre recebêssemos listas no argumento `iterable`,
-`list(iterable)` produz uma cópia do argumento, o que é uma boa prática, considerando que vamos remover itens dali, e o cliente pode não estar esperando que a lista passada seja modificada.footnote:[<<defensive_argument>> em <<ch_refs_mut_mem>> foi dedicado à questão de apelidamento que acabamos de evitar aqui.]
+`list(iterable)` produz uma cópia do argumento, o que é uma boa prática,
+considerando que vamos remover itens dali,
+e o cliente pode não estar esperando que a lista passada seja
+modificada.footnote:[<<defensive_argument>> (<<ch_refs_mut_mem>>)
+trata da questão de apelidamento que acabamos de evitar aqui.]
 
 Chegamos agora à característica dinâmica crucial da goose typing:
 declarar subclasses virtuais com o método `register`((("", startref="GTsubclass13")))((("", startref="ABCsubclass13")))((("", startref="IASsubclass13")))
@@ -1148,7 +1152,7 @@ Claro, o seu `+__subclasshook__+` poderia também verificar assinaturas de méto
 [NOTE]
 ====
 Vimos algo sobre protocolos estáticos((("protocols", "static protocols", id="Pstatic13")))
-em <<protocols_in_fn>> (<<ch_type_hints_def>>).
+em <<protocols_in_fn_sec>> (<<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 checagem de tipos estática sem protocolos não consegue lidar muito bem com as APIs pythônicas.
@@ -1799,7 +1803,7 @@ que  então implementamos da forma tradicional, criando subclasses, e por regist
 Finalizamos aquela seção vendo como o método especial `+__subclasshook__+` permite às ABCs suportarem a tipagem estrutural, pelo reconhecimento de classes não-relacionadas, mas que fornecem os métodos que preenchem os requisitos da interface definida na ABC.
 
 A última grande seção foi a <<static_protocols_sec>>,
-onde retomamos o estudo do duck typing estático, que havia começado no <<ch_type_hints_def>>, em <<protocols_in_fn>>.
+onde retomamos o estudo do duck typing estático, que havia começado no <<ch_type_hints_def>>, 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 consideração as dicas de tipo, tornando a tipagem estrutural mais confiável.
 Então falamos sobre o projeto e a codificação de um protocolo estático e como estendê-lo.
@@ -1864,8 +1868,9 @@ Ele também esta disponível na web, no excelente site do Doug https://fpy.li/13
 Hellmann também usa a declaração de ABC no estilo antigo:`PluginBase(metaclass=abc.ABCMeta)` em vez do mais simples `PluginBase(abc.ABC)`, disponível desde Python 3.4.
 
 Quando usamos ABCs, herança múltipla não é apenas comum mas praticamente inevitável,
-porque cada uma das ABCs fundamentais de coleções — `Sequence`, `Mapping`, e `Set`&#x2014; estendem `Collection`, que por sua vez estende múltiplas ABCs
-(veja <<collections_uml>>). Assim, <<ch_inheritance>> é um tópico importante complementar a esse.
+porque cada uma das ABCs fundamentais de coleções (`Sequence`, `Mapping`, `Set`)
+estendem `Collection`, que por sua vez estende múltiplas ABCs
+(veja <<collections_uml>>). Assim, o <<ch_inheritance>> é um complemento importante ao presente capítulo.
 
 A https://fpy.li/13-52[PEP 3119--Introducing Abstract Base Classes] (EN)
 apresenta a justificativa para as ABCs. A https://fpy.li/13-53[PEP 3141--A Type Hierarchy for Numbers] (EN)