vol3: casos especiais de referências cruzadas

Author: ramalho

links/FPY.LI.htaccess

@@ -1485,4 +1485,24 @@ RedirectTemp /c7	https://docs.python.org/pt-br/3.10/reference/datamodel.html#imp
 # vol3 xref links: appended 2026-02-25
 RedirectTemp /c8    https://pythonfluente.com/2/#closures_sec
 RedirectTemp /c9    https://pythonfluente.com/2/#hashable_vector2d_sec
-RedirectTemp /ca    https://pythonfluente.com/2/#memoization_sec
+RedirectTemp /ca    https://pythonfluente.com/2/#memoization_sec
+
+# vol3 xref links: appended 2026-02-27 18:32:42
+RedirectTemp /cb	https://pythonfluente.com/2/#vector_take1_sec
+RedirectTemp /cc	https://pythonfluente.com/2/#python_digs_seq_sec
+RedirectTemp /cd	https://pythonfluente.com/2/#subclasshook_sec
+RedirectTemp /ce	https://pythonfluente.com/2/#cartesian_product_sec
+RedirectTemp /cf	https://pythonfluente.com/2/#tuples_more_than_lists_sec
+RedirectTemp /cg	https://pythonfluente.com/2/#contravariant_types_sec
+RedirectTemp /ch	https://pythonfluente.com/2/#covariant_types_sec
+RedirectTemp /cj	https://pythonfluente.com/2/#variance_rules_sec
+RedirectTemp /ck	https://pythonfluente.com/2/#pattern_matching_seq_interp_sec
+RedirectTemp /cm	https://pythonfluente.com/2/#nonlocal_sec
+RedirectTemp /cn	https://pythonfluente.com/2/#unicodedata_sec
+RedirectTemp /cp	https://pythonfluente.com/2/#vector_dynamic_attrs_sec
+RedirectTemp /cq	https://pythonfluente.com/2/#goose_typing_sec
+RedirectTemp /cr	https://pythonfluente.com/2/#private_protected_sec
+RedirectTemp /cs	https://pythonfluente.com/2/#overriding_class_attributes_sec
+RedirectTemp /ct	https://pythonfluente.com/2/#missing_method_sec
+RedirectTemp /cv	https://pythonfluente.com/2/#functools_partial_sec
+RedirectTemp /cw	https://pythonfluente.com/2/#mult_inherit_mro_sec

online/cap03.adoc

@@ -608,7 +608,7 @@ O mecanismo que faz `defaultdict` funcionar, chamando `default_factory`,
 é o método especial `+__missing__+`, apresentado a seguir.
 
 
-[[missing_method]]
+[[missing_method_sec]]
 ==== O método +__missing__+
 
 Por((("__missing__", id="missing03"))) trás da forma como os mapeamentos
@@ -983,7 +983,7 @@ Os((("dictionaries and sets", "immutable mappings")))((("mappings", "immutable m
 tipos de mapeamentos disponíveis na biblioteca padrão são todos mutáveis,
 mas pode ser desejável impedir que os usuários mudem um mapeamento por acidente.
 Um caso de uso concreto pode ser encontrado, novamente, em uma biblioteca de programação de hardware como
-a((("Pingo library"))) _Pingo_, mencionada na <<missing_method>>:
+a((("Pingo library"))) _Pingo_, mencionada na <<missing_method_sec>>:
 o mapeamento `board.pins` representa as portas de GPIO (General Purpose Input/Output, _Entrada/Saída Genérica_)
 em um dispositivo.
 Dessa forma, seria útil evitar atualizações descuidadas de `board.pins`,

online/cap22.adoc

@@ -1599,7 +1599,7 @@ um_objeto.set_contagem(um_objeto.get_contagem() + 1)
 
 Algumas vezes, ao projetar uma API, me pergunto se todo método que não recebe argumentos (além de `self`) é uma função pura (isto é, devolve um valor mas não tem efeitos colaterais) não deveria ser substituído por uma propriedade somente de leitura. Neste capítulo, o método `LineItem.subtotal` (no <<lineitem_class_v2prop_class>>) seria um bom candidato a se tornar uma propriedade somente para leitura. Claro, isso exclui métodos projetados para modificar o objeto, tal como `my_list.clear()`. Seria uma péssima ideia transformar isso em uma propriedade, de tal forma que o mero acesso a `my_list.clear` apagaria o conteúdo da lista!
 
-Na biblioteca GPIO https://fpy.li/22-29[_Pingo_] (mencionada na <<missing_method>>), da qual sou co-autor, grande parte da API do usuário está baseada em propriedades. Por exemplo, para ler o valor atual de uma porta analógica, o usuário escreve `pin.value`, e definir o modo de uma porta digital é escrito `pin.mode = OUT`. Por trás da cortina, ler o valor de uma porta analógica ou definir o modo de uma porta digital pode implicar em bastante código, dependendo do driver específico da placa. Decidimos usar propriedades no Pingo porque queríamos que a API fosse confortável de usar até mesmo em ambientes interativos como um Jupyter Notebook, e achamos que `pin.mode = OUT` é mais fácil para os olhos e para os dedos que `pin.set_mode(OUT)`.
+Na biblioteca GPIO https://fpy.li/22-29[_Pingo_] (mencionada na <<missing_method_sec>>), da qual sou co-autor, grande parte da API do usuário está baseada em propriedades. Por exemplo, para ler o valor atual de uma porta analógica, o usuário escreve `pin.value`, e definir o modo de uma porta digital é escrito `pin.mode = OUT`. Por trás da cortina, ler o valor de uma porta analógica ou definir o modo de uma porta digital pode implicar em bastante código, dependendo do driver específico da placa. Decidimos usar propriedades no Pingo porque queríamos que a API fosse confortável de usar até mesmo em ambientes interativos como um Jupyter Notebook, e achamos que `pin.mode = OUT` é mais fácil para os olhos e para os dedos que `pin.set_mode(OUT)`.
 
 Apesar de achar a solução de Smalltalk e de Ruby mais limpa, acho que a abordagem de Python faz mais sentido que a de Java. Podemos começar simples, programando elementos de dados como atributos públicos, pois sabemos que eles sempre podem ser encapsulados por propriedades (ou descritores, dos quais falaremos no próximo capítulo).((("", startref="meyerua22")))((("", startref="uaccess22")))((("", startref="Suaccess22")))
 

online/cap24.adoc

@@ -1515,7 +1515,7 @@ Claramente, o truque está em `WilyDict`.
 Quando Python processa o espaço de nomes da classe do usuário e lê `banana`, ele
 procura aquele nome no mapeamento fornecido por `+__prepare__+`: uma instância
 de `WilyDict` que implementa o método `+__missing__+`, tratado na
-<<missing_method>>.
+<<missing_method_sec>>.
 
 A instância de `WilyDict` inicialmente não contém uma chave
 `'banana'`, então o método `+__missing__+` é acionado. Ele cria um item na hora,