cap15: paginação

Author: ramalho

code/15-more-types/cafeteria/covariant.py

@@ -16,7 +16,6 @@ class OrangeJuice(Juice):
 # tag::BEVERAGE_TYPES[]
 T_co = TypeVar('T_co', covariant=True)  # <1>
 
-
 class BeverageDispenser(Generic[T_co]):  # <2>
     def __init__(self, beverage: T_co) -> None:
         self.beverage = beverage
@@ -33,7 +32,6 @@ def install(dispenser: BeverageDispenser[Juice]) -> None:  # <3>
 # tag::INSTALL_JUICE_DISPENSERS[]
 juice_dispenser = BeverageDispenser(Juice())
 install(juice_dispenser)
-
 orange_juice_dispenser = BeverageDispenser(OrangeJuice())
 install(orange_juice_dispenser)
 # end::INSTALL_JUICE_DISPENSERS[]

online/cap14.adoc

@@ -1454,8 +1454,7 @@ https://fpy.li/14-51[_The End Of Object Inheritance & The Beginning Of A New Mod
 na PyCon 2013. Fackler e Manista falam sobre organizar sistemas em torno de
 interfaces e das funções que lidam com os objetos que implementam aquelas
 interfaces, evitando o acoplamento forte e os pontos de falha de classes e da
-herança. Isso me lembrou muito a maneira de pensar do Go, mas aqui os autores a
-defendem para Python.
+herança. É o modo de pensar da comunidade Go, aplicado ao Python.
 
 .Soapbox
 ****

online/cap15.adoc

@@ -1920,9 +1920,11 @@ Algumas vezes essa é a única solução com custo-benefício positivo.
 
 **Notação de variância em outras linguagens**
 
+**Notação de variância em outras linguagens**
+
 A variância((("Soapbox sidebars", "variance notation in other languages")))((("variance",
 "variance notation in other languages"))) é um tópico complicado,
-e a sintaxe das dicas de tipo de Python não é tão boa quanto poderia ser.
+e a sintaxe das dicas de tipo de Python deixa a desejar.
 Esta citação direta da PEP 484 evidencia isso:
 
 [quote]
@@ -1939,12 +1941,23 @@ ____
 Se esse é o caso, por que a covariância e a contravarância são declaradas com
 `TypeVar` e não na classe genérica?
 
-Os autores da PEP 484 trabalharam sob a severa restrição auto-imposta de
-suportar dicas de tipo sem fazer qualquer modificação no interpretador. Isso
-exigiu a introdução de `TypeVar` para definir variáveis de tipo, e também levou
-ao abuso de `[]` para fornecer a sintaxe `Klass[T]` para genéricos—em vez da
+Os autores da PEP 484 optaram por introduzir dicas de tipo sem fazer
+qualquer modificação no interpretador.
+Em Python, todo identificador aparece pela primeira vez no código-fonte
+de um módulo através de uma
+atribuição, ou uma instrução especial como `import`, `class`, ou  `def`.
+Por isso tiveram que criar `TypeVar` para declarar uma variável de tipo
+através de uma atribuição:
+
+[source, python]
+----
+T = TypeVar('T')
+----
+
+Para não mexer no _parser_, reutilizaram o operador `[]` na sintaxe
+`Klass[T]` para genéricos—em vez da
 notação `Klass<T>` usada em outras linguagens populares, incluindo C#, Java,
-Kotlin e TypeScript. Nenhuma dessas linguagens exige que variáveis de tipo seja
+Kotlin e TypeScript. Estas linguagens não exigem que variáveis de tipo sejam
 declaradas antes de serem usadas.
 
 Além disso, a sintaxe do Kotlin e do C# torna claro se um parâmetro de tipo é
@@ -1961,9 +1974,7 @@ class BeverageDispenser<out T> {
 ----
 
 O modificador `out` no parâmetro de tipo formal significa que `T` é um tipo de
-_output_ (saída)), e portanto `BeverageDispenser` é covariante.
-
-[role="pagebreak-before less_space"]
+_output_ (saída), e portanto `BeverageDispenser` é covariante.
 Você provavelmente consegue adivinhar como `TrashCan` seria declarada:
 
 [source, kotlin]
@@ -1974,15 +1985,13 @@ class TrashCan<in T> {
 ----
 
 Dado `T` como um parâmetro de tipo formal de _input_ (entrada),
-segue que `TrashCan` é contravariante.
-
+então `TrashCan` é contravariante.
 Se nem `in` nem `out` aparecem, então a classe é invariante naquele parâmetro.
 
-É fácil lembrar das <<variance_rules_sec>> quando `out` e `in` são usado nos
-parâmetros de tipo formais.
-
-Isso sugere que uma boa convenção para nomenclatura de variáveis de tipo
-covariante e contravariantes no Python seria:
+É fácil lembrar das regras gerais de variância (<<variance_rules_sec>>)
+quando `out` e `in` são usados nos parâmetros de tipo formais.
+Isso sugere uma convenção melhor para nomear de variáveis de tipo
+covariantes e contravariantes:
 
 [source, python]
 ----
@@ -2001,7 +2010,7 @@ class TrashCan(Generic[T_in]):
     ...
 ----
 
-Será que é tarde demais para modificar a convenção de nomenclatura definida na
-PEP 484?
+Será tarde demais para adotar `T_out` e `T_in` em vez de
+`T_co` e `T_contra` que foram sugeridos na PEP 484?
 
 ****

vol2/README.md

@@ -15,5 +15,5 @@ e faço as demais tarefas nestas cópias especiais para impressão.
 |✅ |✅ |✅ |✅ |✅ |✅ |✅ |✅ |`/vol2`| refazer referências entre volumes|
 |✅ |✅ |✅ |✅ |✅ |✅ |✅ |✅ |`/vol2`| encurtar links entre volumes |
 |✅ |✅ |✅ |✅ |✅ |✅ |✅ |✅ |`/vol2`| exibir capítulo alvo em xrefs para exemplos de outros capítulos |
-|✅ |✅ |✅ |✅ |✅ |✅ |   |   |`/vol2`| rever paginação   |
+|✅ |✅ |✅ |✅ |✅ |✅ |✅ |   |`/vol2`| rever paginação   |
 

vol2/cap14.adoc

@@ -1469,8 +1469,7 @@ https://fpy.li/14-51[_The End Of Object Inheritance & The Beginning Of A New Mod
 na PyCon 2013. Fackler e Manista falam sobre organizar sistemas em torno de
 interfaces e das funções que lidam com os objetos que implementam aquelas
 interfaces, evitando o acoplamento forte e os pontos de falha de classes e da
-herança. Isso me lembrou muito a maneira de pensar do Go, mas aqui os autores a
-defendem para Python.
+herança. É o modo de pensar da comunidade Go, aplicado ao Python.
 
 .Soapbox
 ****
@@ -1578,6 +1577,7 @@ envolvida, e está claro que uma mixin em Ruby não influencia o tipo da classe
 onde que a utiliza. Isto oferece os benefícios das mixins, evitando muitos de
 seus problemas mais comuns.
 
+<<<
 Duas novas linguagens orientadas a objetos que estão recebendo muita atenção
 limitam severamente a herança: Go e Julia. Ambas giram em torno de programar
 "objetos" implementando "métodos", e suportam https://fpy.li/7b[«polimorfismo»],