cap14: revisão de estilo

Author: ramalho

links/fpy-deploy.sh links/deploy-fpy.shlinks/fpy-deploy.sh renamed to links/deploy-fpy.sh

@@ -74,7 +74,7 @@ A <<lru_cache_sec>> apresenta também o uso de `lru_cache`
 sem argumentos, uma novidade do Python 3.8.
 
 Expandi a <<generic_functions_sec>> para incluir dicas de tipo, a sintaxe
-recomendada de usar `functools.singledispatch` desde o Python 3.7.
+recomendada para usar `functools.singledispatch` desde o Python 3.7.
 
 A <<parameterized_dec_sec>> agora inclui o <<clockdeco_param_cls_ex>>,
 que usa uma classe e não uma clausura para implementar um decorador.
@@ -1145,6 +1145,7 @@ e a sequência inteira é apresentada como uma lista HTML.
 <6> Mostra `Fraction` como uma fração.
 <7> Mostra `float` e `Decimal` com a fração equivalente aproximada.
 
+[[single_dispatch_sec]]
 ===== Despacho único de funções
 
 Como não temos no Python a sobrecarga de métodos ao estilo de Java, não podemos

online/cap09.adoc

@@ -23,17 +23,17 @@ herança e criação de subclasses. Vou presumir um entendimento básico destes
 conceitos, que você pode ter aprendido lendo
 https://fpy.li/6w[O Tutorial de Python],
 ou trabalhando com outra linguagem orientada a objetos, tal como
-Java, C# ou {cpp}. Aqui vamos nos concentrar em quatro características de
+Java, C# ou {cpp}. Vamos nos concentrar em quatro características de
 Python:
 
 * A função `super()`
-* As armadilhas na criação de subclasses de tipos embutidos
+* Armadilhas na criação de subclasses de tipos embutidos
 * Herança múltipla e a ordem de resolução de métodos
 * Classes mixin
 
 Herança múltipla acontece quando uma classe tem mais de uma classe base.
 Ela existe em {cpp}, mas não em Java e C#.
-Muitos consideram que a herança múltipla não vale a
+Muitos consideram que a herança múltipla não vale
 os problemas que causa. Ela foi deliberadamente deixada de fora de
 Java, após supostamente ser usada em excesso nos primeiras bases de código em {cpp}.
 
@@ -44,7 +44,7 @@ quando necessário.
 Em 2021, quando escrevo essas linhas, há uma forte reação contra o uso excessivo
 de herança em geral—não apenas herança múltipla—porque superclasses e subclasses
 são fortemente acopladas, ou seja, interdependentes. Esse acoplamento forte
-significa que modificações em uma classe pode ter efeitos inesperados e de longo
+significa que modificações em uma classe podem ter efeitos inesperados e de longo
 alcance em suas subclasses, tornando os sistemas frágeis e difíceis de entender.
 
 Entretanto, ainda temos que dar manutenção a sistemas existentes, que podem ter
@@ -182,7 +182,7 @@ Os parâmetros são:
     O objeto (para chamadas a métodos de instância) ou classe (para chamadas a
     métodos de classe) que será o receptor da chamada ao
     método.footnote:[Adotamos o termo "receptor" como tradução para _receiver_,
-    que é o objeto `o` vinculado um método `m` no momento da chamada `o.m()`.]
+    que é o objeto `x` vinculado um método `m` no momento da chamada `x.m()`.]
     Por default, é `self` se a chamada `super()` acontece no corpo de um método
     de instância.
 
@@ -407,7 +407,9 @@ linguagem que implemente herança múltipla precisa lidar com o
 potencial conflito de nomes, quando superclasses contêm métodos com nomes
 iguais. Este é o chamado "problema do losango" (_diamond problem_),
 ilustrado na <<diamond_uml>> e no <<ex_diamond>>, onde da hiearquia
-começa na classe base `Root` (raiz) e termina na classe `Leaf` (folha).
+começa na classe base `Root` (raiz) e termina na classe `Leaf`
+(folha).footnote:[Adotamos a convenção dos computólogos
+e desenhamos árvores de cabeça para baixo: a raiz no topo, as folhas na base.]
 
 [[diamond_uml]]
 .Esquerda: Sequência de ativação para a chamada `leaf1.ping()`. Direita: Sequência de ativação para a chamada `leaf1.pong()`.
@@ -1161,7 +1163,7 @@ class ListView(MultipleObjectTemplateResponseMixin, BaseListView):
 
 O corpo de `ListView` é vaziofootnote:[NT: a doctring diz "Renderiza alguma
 lista de objetos, definida por `self.model` ou `self.queryset`. `self.queryset`
-na verdade pode ser qualquer iterável de itens, não apenas um queryset."], mas a
+na pode ser qualquer iterável de itens, não apenas um queryset."], mas a
 classe fornece um serviço útil: ela une uma mixin e uma classe base que devem
 ser usadas em conjunto.
 
@@ -1388,11 +1390,11 @@ https://fpy.li/descr101[_Unifying types and classes in Python 2.2_]
 (Unificando tipos e classes em Python 2.2), de Guido van Rossum. Desde então, nada
 realmente importante mudou nesses recursos. Python 2.2 foi uma proeza fantástica
 de evolução da linguagem, adicionando vários novos recursos poderosos em um todo
-coerente, sem quebrar a compatibilidade com versões anteriores. Os novo recursos
+coerente, sem quebrar a compatibilidade com versões anteriores. Os novos recursos
 eram 100% opcionais. Para usá-los, bastava programar explicitamente uma
-subclasse de `object`—direta ou indiretamente—, para criar uma assim chamada
-"classe no novo estilo". No Python 3, todas as classes são subclasses de
-`object`.
+subclasse de direta ou indirta de `object`, para criar uma assim chamada
+_new-style class_ (classe no novo estilo) . No Python 3,
+todas as classes são subclasses de `object`.
 
 O _Python Cookbook_, 3ª ed., de David Beazley e Brian K. Jones (O'Reilly) inclui
 várias receitas mostrando o uso de `super()` e de classes mixin. Você pode
@@ -1411,17 +1413,17 @@ 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>>. Essa
-é a natureza de `super`. Ele é simples de usar em casos de uso básicos, mas é
+com descritores, um conceito que estudaremos apenas no <<ch_descriptors>>. 
+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.
 
-Apesar dos títulos daqueles posts, o problema não é exatamente com a função
-embutida `super`—que no Python 3 não é tão feia quanto era no Python 2. A
-questão real é a herança múltipla, algo inerentemente complicado e traiçoeiro.
+Apesar dos títulos daqueles posts, o problema não é exatamente a função
+embutida `super`—que no Python 3 ficou mais fácil de usar do que era no Python 2.
+A questão real é a herança múltipla, algo inerentemente complicado e traiçoeiro.
 Michele Simionato vai além da crítica, e de fato oferece uma solução em seu
 https://fpy.li/14-42[_Setting Multiple Inheritance Straight_]
-(Colocando a Herança Múltipla em seu Lugar):
+(Colocando a herança múltipla em seu devido lugar):
 ele implementa _traits_ ("traços"), uma forma explícita de mixin originada na linguagem Self.
 Simionato escreveu, em seu blog, uma longa série de posts sobre herança múltipla em Python, incluindo
 https://fpy.li/14-43[_The wonders of cooperative inheritance, or using super in Python 3_]
@@ -1440,7 +1442,7 @@ Grady Booch et al., e o recomendo fortemente como uma introdução geral ao
 pensamento orientado a objetos, independente da linguagem de programação. É um
 dos raros livros que trata da herança múltipla sem preconceitos.
 
-Hoje, mais que nunca, é de bom tom evitar a herança, então cá estão duas
+Hoje, mais que nunca, aconselha-se evitar a herança. Então cá estão duas
 referências sobre como fazer isso. Brandon Rhodes escreveu
 https://fpy.li/14-49[_The Composition Over Inheritance Principle_]
 (O princípio da composição antes da herança), parte de seu excelente guia
@@ -1462,7 +1464,7 @@ defendem para Python.
 [quote, Alan Kay, The Early History of Smalltalk ("Os Primórdios de Smalltalk")]
 ____
 
-[Nós] começamos a defender a ideia de herança como uma maneira de permitir que
+[...] começamos a defender a ideia de herança como uma maneira de permitir que
 iniciantes pudessem construir [algo] a partir de frameworks que só poderiam ser
 projetadas por especialistasfootnote:[Alan Kay, _The Early History of Smalltalk_
 (Os Promórdios de Smalltalk), na SIGPLAN Not. 28, 3 (março de 1993),
@@ -1475,73 +1477,102 @@ ____
 A((("inheritance and subclassing", "Soapbox discussion",
 id="IASsoap14")))((("Soapbox sidebars", "multilevel class hierarchies"))) imensa
 maioria dos programadores escreve aplicações, não frameworks. Mesmo aqueles que
-escrevem frameworks provavelmente passam muito (ou a maior parte) de seu tempo
+escrevem frameworks provavelmente passam boa parte de seu tempo
 escrevendo aplicações. Quando escrevemos aplicações, normalmente não precisamos
 criar hierarquias de classes. No máximo escrevemos classes que são subclasses de
 ABCs ou de outras classes oferecidas pelo framework. Como desenvolvedores de
 aplicações, é muito raro precisarmos escrever uma classe que funcionará como
-superclasse de outra. As classes que escrevemos são, quase sempre, "classes
-folha" (isto é, folhas na árvore de herança).
+superclasse de outra. Quase sempre as classes que escrevemos são classes
+folha: classes concretas sem subclasses.
 
 Se, trabalhando como desenvolvedor de aplicações, você se pegar criando
-hierarquias de classe de múltiplos níveis, quase certamente uma ou mais das
-seguintes alternativas se aplica:
+hierarquias de classe de múltiplos níveis, aposto que está vivendo uma destas
+situações:
 
 * Você está reinventando a roda. Procure um framework ou biblioteca que forneça
-componentes que possam ser reutilizados em sua aplicação.
+componentes você possa reutilizar em sua aplicação.
 
 * Você está usando um framework mal projetado. Procure uma alternativa.
 
-* Você está complicando demais o processo. Lembre-se((("KISS principle"))) do
+* Você está complicando demais. Lembre-se((("KISS principle"))) do
 _Princípio KISS_.
 
 * Você ficou entediado programando aplicações e decidiu criar um novo framework.
 Parabéns e boa sorte!
 
-Também é possível que todas as alternativas acima se apliquem à sua situação:
+Também é possível que todas as alternativas acima descrevam situação:
 você ficou entediado e decidiu reinventar a roda, escrevendo seu próprio
 framework mal projetado e excessivamente complexo, e está sendo forçado a
 programar classe após classe para resolver problemas triviais. Espero que você
 esteja se divertindo, ou pelo menos que esteja sendo pago para fazer isso.
 
 **Tipos embutidos mal-comportados: bug ou _feature_?**
 
-Os((("Soapbox sidebars", "trade-offs of built-ins"))) tipos embutidos `dict`, `list`, e `str` são blocos básicos essenciais do próprio Python, então precisam ser rápidos—qualquer problema de desempenho ali teria severos impactos em praticamente todo o resto.
-É por isso que o CPython adotou atalhos que fazem com que métodos embutidos se comportem mal, ao não cooperarem com os métodos sobrescritos por subclasses.
-Um caminho possível para sair desse dilema seria oferecer duas implementações para cada um desses tipos: um "interno", otimizado para uso pelo interpretador, e um externo, facilmente extensível.
-
-Mas isso nós já temos: `UserDict`, `UserList`,
-e `UserString` não são tão rápidos quanto seus equivalentes embutidos,
-mas são fáceis de estender.
-A abordagem pragmática tomada pelo CPython significa que  também podemos usar,
-em nossas próprias aplicações, as implementações altamente otimizadas mas difíceis estender.
-E isso faz sentido, considerando que não é tão frequente precisarmos de um mapeamento,
-uma lista ou uma string customizados, mas usamos `dict`, `list`, e `str` diariamente.
-Só precisamos estar cientes dos compromissos envolvidos.
-
-
-
-[role="soapbox-title"]
-Herança através das linguagens
-
-Alan Kay((("Soapbox sidebars", "inheritance across languages"))) criou o termo "orientado a objetos", e Smalltalk tinha apenas herança simples, apesar de existirem versões com diferentes formas de suporte a herança múltipla, incluindo os dialetos modernos de Smalltalk, Squeak e Pharo, que suportam _traits_ ("traços")—um dispositivo de linguagem que pode substituir classes mixin, mas evita alguns dos problemas da herança múltipla.
-
-A primeira linguagem popular a implementar herança múltipla foi o {cpp}, e esse recurso foi abusado o suficiente para que o Java—criado para ser um substituto do {cpp}—fosse projetado sem suporte a herança múltipla de implementação (isto é, sem classes mixin). Quer dizer, isso até o Java 8 introduzir os métodos default, que tornam interfaces muito similares às classes abstratas usadas para definir interfaces em {cpp} e em Python.
-Depois de Java, a linguagem da JVM mais usada é provavelmente o Scala, que implementa _traits_.
+Os((("Soapbox sidebars", "trade-offs of built-ins"))) tipos embutidos `dict`,
+`list`, e `str` são blocos básicos essenciais do próprio Python, então precisam
+ser rápidos—qualquer problema de desempenho ali teria severos impactos em
+praticamente todo o resto. É por isso que o CPython adotou atalhos que fazem com
+que muitos métodos embutidos escritos em C se comportem mal, ao não cooperarem
+com os métodos sobrescritos por subclasses em Python. 
+
+Uma solução para este dilema seria oferecer duas implementações para cada um
+desses tipos: uma "interno", otimizada para uso pelo interpretador, e uma externa,
+facilmente extensível. 
+
+Mas veja só, isso nós já temos: `UserDict`, `UserList`, e `UserString` não são
+tão rápidos quanto seus equivalentes embutidos, mas são fáceis de estender. A
+abordagem pragmática tomada pelo CPython significa que também podemos usar, em
+nossas próprias aplicações, as implementações altamente otimizadas mas difíceis
+estender. E isso faz sentido, considerando que não é tão frequente precisarmos
+de um mapeamento, uma lista ou uma string customizados, mas usamos `dict`,
+`list`, e `str` diariamente. Só precisamos estar cientes dos compromissos
+envolvidos.
+
+
+**Herança através das linguagens**
+
+Alan Kay((("Soapbox sidebars", "inheritance across languages"))) criou o termo
+"orientado a objetos", e Smalltalk tinha apenas herança simples, apesar de
+existirem versões com diferentes formas de suporte a herança múltipla, incluindo
+os dialetos modernos de Smalltalk, Squeak e Pharo, que suportam _traits_
+("traços")—um dispositivo de linguagem que pode substituir classes mixin, mas
+evita alguns dos problemas da herança múltipla.
+
+A primeira linguagem popular a implementar herança múltipla foi o {cpp}, e esse
+recurso foi abusado o suficiente para que o Java—criado para ser um substituto
+do {cpp}—fosse projetado sem suporte a herança múltipla de implementação (isto
+é, sem classes mixin). Quer dizer, isso até o Java 8 (e Kotlin) permitir métodos
+default, que que aproximam suas interfaces do conceito de classes abstratas
+que temps em Python e {cpp}.
 
 Outras linguagens que suportam _traits_ são versões recentes de PHP e Groovy,
-bem como Rust e Raku—a linguagem antes conhecida como Perl 6.footnote:[Meu amigo e revisor técnico Leonardo Rochael explica isso melhor do que eu poderia:
-"A existência continuada junto com o persistente adiamento da chegada do Perl 6 estava drenando a força de vontade da evolução do próprio Perl. Agora o Perl continua a ser desenvolvido como uma linguagem separada (está na versão 5.34), sem a ameaça de ser descontinuada pela linguagem antes conhecida como Perl 6."]
+bem como Rus, Scala, t e Raku—a linguagem antes conhecida como Perl 6.footnote:[Meu amigo
+e revisor técnico Leonardo Rochael explica isso melhor do que eu poderia: "A
+existência continuada junto com o persistente adiamento da chegada do Perl 6
+estava drenando a força de vontade da evolução do próprio Perl. Agora o Perl
+continua a ser desenvolvido como uma linguagem separada (está na versão 5.34),
+sem a ameaça de ser descontinuada pela linguagem antes conhecida como Perl 6."]
 Então podemos dizer que _traits_ estão na moda em 2021.
 
-Ruby traz uma perspectiva original para a herança múltipla:
-não a suporta, mas introduz mixins como um recurso explícito da linguagem. Uma classe Ruby pode incluir um módulo em seu corpo, e aí os métodos definidos no módulo se tornam parte da implementação da classe.
-Essa é uma forma "pura" de mixin, sem herança envolvida, e está claro que uma mixin Ruby não tem qualquer influência sobre o tipo da classe onde ela é usada.
-Isso 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], mas evitam o termo "classe".
-
-Go não tem qualquer tipo de herança, mas oferece uma sintaxe que facilita a composição. Julia tem uma hierarquia de tipos, mas subtipos não podem herdar estrutura, apenas comportamentos, e só é permitido criar subtipos de tipos abstratos. Além disso, os métodos de Julia são implementados com despacho múltiplo—uma forma mais avançada do mecanismo que vimos na <<generic_functions_sec>>.((("", startref="IASsoap14")))
+Ruby traz uma perspectiva original para a herança múltipla: não a suporta, mas
+introduz mixins como um recurso explícito da linguagem. Uma classe Ruby pode
+incluir um módulo em seu corpo, e aí os métodos definidos no módulo se tornam
+parte da implementação da classe. Essa é uma forma "pura" de mixin, sem herança
+envolvida, e está claro que uma mixin Ruby não tem qualquer influência sobre o
+tipo da classe onde ela é usada. Isso 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],
+mas evitam o termo "classe".
+
+Go não tem qualquer tipo de herança, mas oferece uma sintaxe que facilita a
+composição de suas interfaces e structs. Julia tem uma hierarquia de tipos, mas
+subtipos não podem herdar estrutura, só comportamentos, e só é permitido
+criar subtipos de tipos abstratos. Além disso, os métodos de Julia são
+implementados com despacho múltiplo—uma forma mais avançada do mecanismo de
+despacho único que vimos na <<single_dispatch_sec>>.((("",
+startref="IASsoap14")))
 
 ****