destinatário->receptor, a framework -> o framework

em conformidade com guia-de-estilo.adoc

Author: ramalho

capitulos/cap01.adoc

@@ -29,9 +29,9 @@ Entretanto, se você aprendeu outra linguagem orientada a objetos antes do Pytho
 Essa aparente esquisitice é a ponta de um iceberg que, quando compreendido de forma apropriada, é a chave para tudo aquilo que chamamos de _pythônico_.
 O iceberg se chama o Modelo de Dados do Python, e é a API que usamos para fazer nossos objetos lidarem bem com os aspectos mais idiomáticos da linguagem.
 
-É((("Python Data Model", "overview of"))) possível pensar no modelo de dados como uma descrição do Python na forma de uma framework. Ele formaliza as interfaces dos elementos constituintes da própria linguagem, como sequências, funções, iteradores, corrotinas, classes, gerenciadores de contexto e assim por diante.
+É((("Python Data Model", "overview of"))) possível pensar no modelo de dados como uma descrição do Python na forma de um framework. Ele formaliza as interfaces dos elementos constituintes da própria linguagem, como sequências, funções, iteradores, corrotinas, classes, gerenciadores de contexto e assim por diante.
 
-Quando usamos uma framework, gastamos um bom tempo programando métodos que são chamados por ela. O mesmo acontece quando nos valemos do Modelo de Dados do Python para criar novas classes. O interpretador do Python invoca((("special methods", "purpose of"))) métodos especiais para realizar operações básicas sobre os objetos, muitas vezes acionados por uma sintaxe especial.
+Quando usamos um framework, gastamos um bom tempo programando métodos que são chamados por ela. O mesmo acontece quando nos valemos do Modelo de Dados do Python para criar novas classes. O interpretador do Python invoca((("special methods", "purpose of"))) métodos especiais para realizar operações básicas sobre os objetos, muitas vezes acionados por uma sintaxe especial.
 Os((("special methods", "naming conventions")))((("__ (double underscore)")))((("double underscore (__)"))) nomes dos métodos especiais são sempre precedidos e seguidos de dois sublinhados.
 Por exemplo, a sintaxe `obj[key]` está amparada no método especial `+__getitem__+`.
 Para resolver `my_collection[key]`, o interpretador chama `+my_collection.__getitem__(key)+`.
@@ -674,6 +674,6 @@ A parte _metaobjetos_ se refere aos objetos que são os componentes essenciais d
 Um protocolo de metaobjetos rico permite estender a linguagem para suportar novos paradigmas de programação. Gregor Kiczales, o primeiro autor do _AMOP_, mais tarde se tornou um pioneiro da programação orientada a aspecto, e o autor inicial do AspectJ, uma extensão de Java implementando aquele paradigma.
 A programação orientada a aspecto é muito mais fácil de implementar em uma linguagem dinâmica como Python, e algumas frameworks fazem exatamente isso.
 O exemplo mais importante é a https://fpy.li/1-12[_zope.interface_] (EN),
-parte da framework sobre a qual o sistema de gerenciamento de conteúdo https://plone.org.br/[Plone] é construído.
+parte do framework sobre a qual o sistema de gerenciamento de conteúdo https://plone.org.br/[Plone] é construído.
 ****
 

capitulos/cap05.adoc

@@ -258,7 +258,7 @@ Dada uma instância de tupla nomeada `x`, a chamada `+x._replace(**kwargs)+` dev
 
 ===== Nova classe durante a execução
 
-Apesar da sintaxe de declaração de classe ser mais legível, ela é fixa no código. Uma framework pode ter a necessidade de criar classes de dados durante a execução. Para tanto, podemos usar a sintaxe default de chamada de função de `collections.namedtuple`, que também é suportada por `typing.NamedTuple`. O módulo `dataclasses` oferece a função `make_dataclass`, com o mesmo propósito.
+Apesar da sintaxe de declaração de classe ser mais legível, ela é fixa no código. Um framework pode ter a necessidade de criar classes de dados durante a execução. Para tanto, podemos usar a sintaxe default de chamada de função de `collections.namedtuple`, que também é suportada por `typing.NamedTuple`. O módulo `dataclasses` oferece a função `make_dataclass`, com o mesmo propósito.
 
 Após essa visão geral dos principais recursos das fábricas de classes de dados, vamos examinar cada uma delas mais de perto, começando pela mais simples.((("", startref="DCBmain05")))
 

capitulos/cap07.adoc

@@ -311,7 +311,7 @@ Quando chamados, devolvem um gerador assíncrono para ser usado com `async for`.
 
 Funções geradoras, funções de corrotinas nativas e geradoras assíncronas são diferentes de outros invocáveis: os valores devolvidos tais funções nunca são dados da aplicação, mas objetos que exigem processamento adicional, seja para produzir dados da aplicação, seja para realizar algum trabalho útil.
 Funções geradoras devolvem iteradores. Ambos são tratados no <<iterables2generators>>.
-Funções de corrotinas nativas e funções geradoras assíncronas devolvem objetos que só funcionam com a ajuda de uma framework de programação assíncrona, tal como _asyncio_.
+Funções de corrotinas nativas e funções geradoras assíncronas devolvem objetos que só funcionam com a ajuda de um framework de programação assíncrona, tal como _asyncio_.
 Elas são o assunto do <<async_ch>>.
 
 

capitulos/cap08.adoc

@@ -1972,7 +1972,8 @@ ____
 Acho que bibliotecas com APIs 'pythônicas' são as menos propensas a adotar esse sistema de tipagem, pois ele vai adicionar muito pouco valor a elas.
 ____
 
-Naquela mensagem, Benfield incluiu esse exemplo extremo de uma tentativa de definição de tipo para o argumento de palavra-chave `files` em https://fpy.li/8-53[`requests.request()`]:
+Naquela mensagem, Benfield incluiu esse exemplo extremo de uma tentativa de definição de tipo para o 
+argumento nomeado `files` em https://fpy.li/8-53[`requests.request()`]:
 
 ----
 Optional[

capitulos/cap09.adoc

@@ -1258,7 +1258,15 @@ A https://fpy.li/9-12[PEP 3104--Access to Names in Outer Scopes (_Acesso a Nomes
 
 Em um nível mais teórico, a https://fpy.li/9-13[PEP 227--Statically Nested Scopes (_Escopos Estaticamente Aninhados_)] (EN) documenta a introdução do escopo léxico como um opção no Python 2.1 e como padrão no Python 2.2, explicando a justificativa e as opções de design para a implementação de clausuras no Python.
 
-A https://fpy.li/9-14[PEP 443] (EN) traz a justificativa e uma descrição detalhada do mecanismo de funções genéricas de despacho único. Um antigo (março de 2005) post de blog de Guido van Rossum, https://fpy.li/9-15["Five-Minute Multimethods in Python" (_Multi-métodos em Python em Cinco Minutos_)] (EN), mostra os passos para uma implementação de funcões genéricas (também chamadas multi-métodos) usando decoradores. O código de multi-métodos de Guido é interessante, mas é um exemplo didático. Para ver uma implementação moderna e pronta para ser usada em produção de funções genéricas de despacho múltiplo, veja a https://fpy.li/9-16[Reg] de Martijn Faassen–autor da  https://fpy.li/9-17[Morepath], uma framework web guiada por modelos e compatível com REST.
+A https://fpy.li/9-14[PEP 443] (EN) traz a justificativa e uma descrição detalhada do mecanismo de funções genéricas de despacho único.
+Um post de Guido van Rossum de março de 2005
+https://fpy.li/9-15["Five-Minute Multimethods in Python" (_Multi-métodos em Python em Cinco Minutos_)] (EN),
+mostra os passos para uma implementação de funcões genéricas (também chamadas multi-métodos) usando decoradores.
+O código de multi-métodos de Guido é interessante, mas é apenas um exemplo didático.
+Para conhecer uma implementação de funções genéricas de despacho múltiplo moderna e pronta para uso em produção,
+veja a https://fpy.li/9-16[Reg] de
+Martijn Faassen–autor de https://fpy.li/9-17[Morepath],
+um framework web guiado por modelos e orientado a REST.
 
 [[closures_soapbox]]
 [role="pagebreak-before less_space"]

capitulos/cap10.adoc

@@ -307,12 +307,12 @@ Na próxima seção vamos discutir Comando (_Command_)—outro padrão de projet
 Comando((("functions, design patterns with first-class", "Command pattern", id="FDPcommand10")))((("Command pattern", id="cmmd10")))((("refactoring strategies", "Command pattern", id="RScmmnd10")))((("UML class diagrams", "Command design pattern"))) é outro padrão de projeto que pode ser simplificado com o uso de funções passadas como argumentos. A <<command_uml>> mostra o arranjo das classes nesse padrão.
 
 [[command_uml]]
-.Diagrama de classes UML para um editor de texto controlado por menus, implementado com o padrão de projeto Comando. Cada comando pode ter um destinatário (_receiver_) diferente: o objeto que implementa a ação. Para `PasteCommand`, o destinatário é Document. Para `OpenCommand`, o destinatário á a aplicação.
+.Diagrama de classes UML para um editor de texto controlado por menus, implementado com o padrão de projeto Comando. Cada comando pode ter um receptor (_receiver_) diferente: o objeto que implementa a ação. Para `PasteCommand`, o receptor é Document. Para `OpenCommand`, o receptor á a aplicação.
 image::images/flpy_1002.png[Aplicação do padrão Comando a um editor de texto]
 
-O objetivo de Comando é desacoplar um objeto que invoca uma operação (o _invoker_ ou remetente) do objeto fornecedor que implementa aquela operação (o _receiver_ ou destinatário). No exemplo em _Padrões de Projetos_, cada remetente é um item de menu em uma aplicação gráfica, e os destinatários são o documento sendo editado ou a própria aplicação.
+O objetivo de Comando é desacoplar um objeto que invoca uma operação (o _invoker_ ou remetente) do objeto fornecedor que implementa aquela operação (o _receiver_ ou receptor). No exemplo em _Padrões de Projetos_, cada remetente é um item de menu em uma aplicação gráfica, e os receptors são o documento sendo editado ou a própria aplicação.
 
-A ideia é colocar um objeto `Command` entre os dois, implementando uma interface com um único método, `execute`, que chama algum método no destinatário para executar a operação desejada. Assim, o remetente não precisa conhecer a interface do destinatário, e destinatários diferentes podem ser adaptados com diferentes subclasses de `Command`. O remetente é configurado com um comando concreto, e o opera chamando seu método `execute`. Observe na <<command_uml>> que `MacroCommand` pode armazenar um sequência de comandos; seu método `execute()` chama o mesmo método em cada comando armazenado.
+A ideia é colocar um objeto `Command` entre os dois, implementando uma interface com um único método, `execute`, que chama algum método no receptor para executar a operação desejada. Assim, o remetente não precisa conhecer a interface do receptor, e receptors diferentes podem ser adaptados com diferentes subclasses de `Command`. O remetente é configurado com um comando concreto, e o opera chamando seu método `execute`. Observe na <<command_uml>> que `MacroCommand` pode armazenar um sequência de comandos; seu método `execute()` chama o mesmo método em cada comando armazenado.
 
 Citando _Padrões de Projetos_, "Comandos são um substituto orientado a objetos para _callbacks_." A pergunta é: precisamos de um substituto orientado a objetos para _callbacks_? Algumas vezes sim, mas nem sempre.
 

capitulos/cap11.adoc

@@ -21,7 +21,7 @@ Graças((("Pythonic objects", "building user-defined classes"))) ao Modelo de Da
 
 Nos capítulos anteriores, estudamos o comportamento de vários objetos embutidos. Vamos agora criar classes definidas pelo usuário que se portam como objetos Python reais.
 As classes na sua aplicação provavelmente não precisam nem devem implementar tantos métodos especiais quanto os exemplos nesse capítulo.
-Mas se você estiver escrevendo uma biblioteca ou uma framework, os programadores que usarão suas classes talvez esperem que elas se comportem como as classes fornecidas pelo Python.
+Mas se você estiver escrevendo uma biblioteca ou um framework, os programadores que 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 <<data_model>> terminou, mostrando como implementar vários métodos especiais comumente vistos em objetos Python de diferentes tipos.

capitulos/cap13.adoc

@@ -526,7 +526,7 @@ True
 
 Como se vê, `abc.Sized` reconhece `Struggle` como uma `subclasse`, sem necessidade de registro, já que implementar o método especial chamado `+__len__+` é o suficiente (o método deve ser implementado com a sintaxe e semântica corretas - deve poder ser chamado sem argumentos e retornar um inteiro não-negativo indicando o "comprimento" do objeto; mas qualquer código que implemente um método com nome especial, como `+__len__+`, com uma sintaxe e uma semântica arbitrárias e incompatíveis tem problemas muitos maiores que esses).
 
-Então, aqui está minha mensagem de despedida: sempre que você estiver implementando uma classe que incorpore qualquer dos conceitos representados nas ABCs de `number`, `collections.abc` ou em outra framework que estiver usando, se assegure (caso necessário) de ser uma subclasse ou de registrar sua classe com a ABC correspondente. No início de seu programa usando uma biblioteca ou framework que definam classes que omitiram esse passo, registre você mesmo as classes. Daí, quando precisar verificar se (tipicamente) um argumento é, por exemplo, "uma sequência", verifique se:
+Então, aqui está minha mensagem de despedida: sempre que você estiver implementando uma classe que incorpore qualquer dos conceitos representados nas ABCs de `number`, `collections.abc` ou em outro framework que estiver usando, se assegure (caso necessário) de ser uma subclasse ou de registrar sua classe com a ABC correspondente. No início de seu programa usando uma biblioteca ou framework que definam classes que omitiram esse passo, registre você mesmo as classes. Daí, quando precisar verificar se (tipicamente) um argumento é, por exemplo, "uma sequência", verifique se:
 [source, python3]
 ----
 isinstance(the_arg, collections.abc.Sequence)
@@ -578,7 +578,7 @@ Durante o processo de revisão do _Python Fluente_, Alex me enviou uma email:
 
 [quote]
 ____
-ABCs servem para encapsular conceitos muito genéricos, abstrações, introduzidos por uma framework - coisa como "uma sequência" e "um número exato".
+ABCs servem para encapsular conceitos muito genéricos, abstrações introduzidos por um framework - coisa como "uma sequência" e "um número exato".
 [Os leitores] quase certamente não precisam escrever alguma nova ABC, apenas usar as já existentes de forma correta, para obter 99% dos benefícios sem qualquer risco sério de design mal-feito.
 ____
 
@@ -1834,7 +1834,7 @@ Eu também aprendi bastante em seu post
 https://fpy.li/13-43["Interfaces and Protocols"] (EN) ("Interfaces e Protocolos"),
 comparando `typing.Protocol` com `zope.interface` — um mecanismo mais antigo para definir interfaces em sistemas plug-in fracamente acoplados, usado no
 https://fpy.li/13-44[Plone CMS],
-na https://fpy.li/13-45[Pyramid web framework], e na framework de programação assíncrona
+na https://fpy.li/13-45[Pyramid web framework], e no framework de programação assíncrona
 https://fpy.li/13-46[Twisted],
 um projeto fundado por Glyph.footnote:[Agradeço ao revisor técnico Jürgen Gmach por ter recomentado o post "Interfaces and Protocols".]
 

capitulos/cap16.adoc

@@ -91,9 +91,9 @@ A seção https://docs.python.org/pt-br/3/reference/expressions.html#unary-arith
 
 O pass:[<a href="https://docs.python.org/pt-br/3/reference/datamodel.html#object.__neg__">capítulo "Modelo de Dados"</a>] de _A Referência da Linguagem Python_ também inclui a função embutida `abs()` como um operador unário. O método especial associado é `+__abs__+`, como já vimos.
 
-É fácil suportar operadores unários. Basta implementar o método especial apropriado, que receberá apenas um argumento: `self`. Use a lógica que fizer sentido na sua classe, mas se atenha à regra geral dos operadores: sempre devolva um novo objeto. Em outras palavras, não modifique o destinatário (`self`), crie e devolva uma nova instância do tipo adequado.
+É fácil suportar operadores unários. Basta implementar o método especial apropriado, que receberá apenas um argumento: `self`. Use a lógica que fizer sentido na sua classe, mas se atenha à regra geral dos operadores: sempre devolva um novo objeto. Em outras palavras, não modifique o receptor (`self`), crie e devolva uma nova instância do tipo adequado.
 
-No caso de `-` e `+`, o resultado será provavelmente uma instância da mesma classe de `self`. Para o `+` unário, se o destinatário for imutável você deveria devolver `self`; caso contrário, devolva uma cópia de `self`.
+No caso de `-` e `+`, o resultado será provavelmente uma instância da mesma classe de `self`. Para o `+` unário, se o receptor for imutável você deveria devolver `self`; caso contrário, devolva uma cópia de `self`.
 Para `abs()`, o resultado deve ser um número escalar.
 
 Já no caso de `~`, é difícil determinar o que seria um resultado razoável se você não estiver lidando com bits de um número inteiro.

capitulos/cap17.adoc

@@ -2102,16 +2102,16 @@ que no fim precisa ser controlada por algum código não-trivial, como mostra o
 
 Os exemplos anteriores mostram que o uso direto de corrotinas é incômodo e confuso.
 Acrescente o tratamento de exceções e o método de corrotina `.throw()`, e os exemplos ficam ainda mais complicados.
-Não vou tratar de `.throw()` nesse livro porque—como `.send()`—ele só é útil para controlar corrotinas "manualmente", e não recomendo fazer isso, a menos que você esteja criando uma nova framework baseada em corrotinas do zero .
+Não vou tratar de `.throw()` nesse livro porque—como `.send()`—ele só é útil para controlar corrotinas "manualmente", e não recomendo fazer isso, a menos que você esteja criando um novo framework baseado em corrotinas do zero .
 
 [NOTE]
 ====
 Se você estiver interessado em um tratamento mais aprofundado de corrotinas clássicas—incluindo o método `.throw()`—por favor veja 
 https://fpy.li/oldcoro["Classic Coroutines" (_Corrotinas Clássicas_)] (EN) no site que acompanha o livro, pass:[<a href="http://fluentpython.com" class="orm:hideurl"><em>fluentpython.com</em></a>].
-Aquele texto inclui pseudo-código similar ao Python detalhando como `yield from` controla geradoras e corrotinas, bem como uma pequena simulação de eventos discretos, demonstrando uma forma de concorrência usando corrotinas sem uma framework de programação assíncrona.
+Aquele texto inclui pseudo-código similar ao Python detalhando como `yield from` controla geradoras e corrotinas, bem como uma pequena simulação de eventos discretos, demonstrando uma forma de concorrência usando corrotinas sem um framework de programação assíncrona.
 ====
 
-Na prática, realizar trabalho produtivo com corrotinas exige o suporte de uma framework especializada. 
+Na prática, realizar trabalho produtivo com corrotinas exige o suporte de um framework especializada. 
 É isso que `asyncio` oferecia para corrotinas clássicas lá atrás, no Python 3.3.
 Com o advento das corrotinas nativas no Python 3.5, os desenvolvedores principais do Python estão gradualmente eliminando o suporte a corrotinas clássicas no `asyncio`.
 Mas os mecanismos subjacentes são muito similares.