a framework->o framework

conforme guia-de-estilo.adoc

Author: ramalho

Prefacio.adoc

@@ -115,7 +115,7 @@ O último capítulo na <<data_structures_part>> versa sobre o ciclo de vida dos
 <<classes_protocols_part>>:: Agora((("classes", "topics covered"))) o foco se volta para a criação "manual" de classes—em contraste com o uso de fábricas de classe vistas no <<data_class_ch>>.
 Como qualquer linguagem orientada a objetos, Python tem seu conjunto particular de recursos que podem ou não estar presentes na linguagem na qual você ou eu aprendemos programação baseada em classes. Os capítulos explicam como criar suas próprias coleções, classes base abstratas (ABCs) e protocolos, bem como as formas de lidar com herança múltipla e como implementar a sobrecarga de operadores, quando fizer sentido.O <<more_types_ch>> continua a conversa sobre dicas de tipo.
 
-<<control_flow_part>>:: Nesta((("control flow"))) parte são tratados os mecanismos da linguagem e as bibliotecas que vão além do controle de fluxo tradicional, com condicionais, laços e sub-rotinas. Começamos com os geradores, visitamos a seguir os gerenciadores de contexto e as corrotinas, incluindo a desafiadora mas poderosa sintaxe do `yield from`. O <<with_match_ch>> inclui um exemplo significativo, usando _pattern matching_ em um interpretador de linguagem simples mas funcional. O <<concurrency_models_ch>> é novo, apresentando uma visão geral das alternativas para processamento concorrente e paralelo no Python, suas limitações, e como a arquitetura de software permite ao Python operar na escala da Web. Reescrevi o capítulo sobre _programação assíncrona_, para enfatizar os recursos centrais da linguagem—por exemplo, `await`, `async def`, `async for` e `async with`, e mostrar como eles são usados com _asyncio_ e outras frameworks.
+<<control_flow_part>>:: Nesta((("control flow"))) parte são tratados os mecanismos da linguagem e as bibliotecas que vão além do controle de fluxo tradicional, com condicionais, laços e sub-rotinas. Começamos com os geradores, visitamos a seguir os gerenciadores de contexto e as corrotinas, incluindo a desafiadora mas poderosa sintaxe do `yield from`. O <<with_match_ch>> inclui um exemplo significativo, usando _pattern matching_ em um interpretador de linguagem simples mas funcional. O <<concurrency_models_ch>> é novo, apresentando uma visão geral das alternativas para processamento concorrente e paralelo no Python, suas limitações, e como a arquitetura de software permite ao Python operar na escala da Web. Reescrevi o capítulo sobre _programação assíncrona_, para enfatizar os recursos centrais da linguagem—por exemplo, `await`, `async def`, `async for` e `async with`, e mostrar como eles são usados com _asyncio_ e outros frameworks.
 
 <<metaprog_part>>:: Essa((("metaprogramming"))) parte começa com uma revisão de técnicas para criação de classes com atributos criados dinamicamente para lidar com dados semi-estruturados, tal como conjuntos de dados JSON. A seguir tratamos do mecanismo familiar das propriedades, antes de mergulhar no funcionamento do acesso a atributos de objetos no Python em um nível mais baixo, usando descritores. A relação entre funções, métodos e descritores é explicada. Por toda a <<metaprog_part>>, a implementação passo a passo de uma biblioteca de validação de campos revela questões sutis, levando às ferramentas avançadas do capítulo final: decoradores de classes e metaclasses.
 

capitulos/cap01.adoc

@@ -672,7 +672,7 @@ _The Art of the Metaobject Protocol (AMOP)_ (_A Arte do protocolo de metaobjetos
 A parte _metaobjetos_ se refere aos objetos que são os componentes essenciais da própria linguagem. Nesse contexto, _protocolo_ é sinônimo de _interface_. Assim, um _protocolo de metaobjetos_ é um sinônimo chique para modelo de objetos: uma API para os elementos fundamentais da linguagem.
 
 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.
+A programação orientada a aspecto é muito mais fácil de implementar em uma linguagem dinâmica como Python, e alguns frameworks fazem exatamente isso.
 O exemplo mais importante é a https://fpy.li/1-12[_zope.interface_] (EN),
 parte do framework sobre a qual o sistema de gerenciamento de conteúdo https://plone.org.br/[Plone] é construído.
 ****

capitulos/cap04.adoc

@@ -558,10 +558,13 @@ Vamos agora ver como tratar arquivos de texto no Python 3.((("", startref="UTVun
 
 A((("Unicode text versus bytes", "handling text files", id="UTVtext04")))((("text files, handling", id="Tfile04"))) melhor prática para lidar com E/S de texto é o((("Unicode sandwich"))) "Sanduíche de Unicode" (_Unicode  sandwich_)
 (<<unicode_sandwich_fig>>).footnote:[A primeira vez que vi o termo "Unicode sandwich" (_sanduíche de Unicode_) foi na excelente apresentação de Ned Batchelder, https://fpy.li/4-10["Pragmatic Unicode" (_Unicode pragmático_) (EN)] na US PyCon 2012.]
-Isso significa que os `bytes` devem ser decodificados para `str` o mais cedo possível na entrada (por exemplo, ao abrir um arquivo para leitura).
-O "recheio" do sanduíche é a lógica do negócio de seu programa, onde o tratamento do texto é realizado exclusivamente sobre objetos `str`.
-Você nunca deveria codificar ou decodificar no meio de outro processamento. Na saída, as `str` são codificadas para `bytes` o mais tarde possível.
-A maioria das frameworks web funcona assim, e raramente encostamos em `bytes` ao usá-las.
+Isso significa que os `bytes` devem ser decodificados para `str` o mais cedo possível na entrada
+(por exemplo, ao abrir um arquivo para leitura).
+O "recheio" do sanduíche é a lógica do negócio de seu programa,
+onde o tratamento do texto é realizado exclusivamente sobre objetos `str`.
+Você nunca deveria codificar ou decodificar no meio de outro processamento.
+Na saída, as `str` são codificadas para `bytes` o mais tarde possível.
+A maioria dos frameworks web funciona assim, e raramente tocamos em `bytes` ao usá-los.
 No Django, por exemplo, suas views devem produzir `str` em Unicode; o próprio Django se encarrega de codificar a resposta para `bytes`, usando UTF-8 como default.
 
 O Python 3 torna mais fácil seguir o conselho do sanduíche de Unicode, pois o embutido `open()` executa a decodificação necessária na leitura e a codificação ao escrever arquivos em modo texto. Dessa forma, tudo que você recebe de `my_file.read()` e passa para `my_file.write(text)` são objetos `str`.

capitulos/cap09.adoc

@@ -197,13 +197,16 @@ Considerando((("decorators and closures", "registration decorators")))((("regist
 * A função do decorador é definida no mesmo módulo das funções decoradas. Em geral, um decorador real é definido em um módulo e aplicado a funções de outros módulos.
 * O decorador `register` devolve a mesma função recebida como argumento. Na prática, a maior parte dos decoradores define e devolve uma função interna.
 
-Apesar do decorador `register` no <<registration_ex>> devolver a função decorada inalterada, aquela técnica não é inútil. Decoradores parecidos são usados por muitas frameworks Python para adicionar funções a um registro central—por exemplo, 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.
+Apesar do decorador `register` no <<registration_ex>> devolver a função decorada inalterada, a técnica não é inútil.
+Decoradores parecidos são usados por muitos frameworks Python para adicionar funções a um registro central—por exemplo,
+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 <<rethinking_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.
-E código que usa funções internas quase sempre depende de clausuras para operar corretamente.
+Código que usa funções internas quase sempre depende de clausuras para operar corretamente.
 Para entender as clausuras, precisamos dar um passo atrás e revisar como o escopo de variáveis funciona no Python.
 
 === Regras de escopo de variáveis
@@ -1230,7 +1233,7 @@ Percorremos((("decorators and closures", "overview of"))) um terreno acidentado
 
 Partimos de um decorador simples `@register`, sem uma função interna, e terminamos com um `@clock()` parametrizado envolvendo dois níveis de funções aninhadas.
 
-Decoradores de registro, apesar de serem essencialmente simples, tem aplicações reais nas frameworks Python. Vamos aplicar a ideia de registro em uma implementação do padrão de projeto Estratégia, no <<rethinking_design_patterns>>.
+Decoradores de registro, apesar de serem essencialmente simples, tem aplicações reais nos frameworks Python. Vamos aplicar a ideia de registro em uma implementação do padrão de projeto Estratégia, no <<rethinking_design_patterns>>.
 
 Entender como os decoradores realmente funcionam exigiu falar da diferença entre _tempo de importação_ e _tempo de execução_. Então mergulhamos no escopo de variáveis, clausuras e a nova declaração `nonlocal`. Dominar as clausuras e `nonlocal` é valioso não apenas para criar decoradores, mas também para escrever programas orientados a eventos para GUIs ou E/S assíncrona com _callbacks_, e para adotar um estilo funcional quando fizer sentido.
 

capitulos/cap13.adoc

@@ -570,7 +570,7 @@ Normalmente _não_ é bom ter uma série de `if/elif/elif` com verificações de
 Por outro lado, não há problema em executar uma verificação com `isinstance` contra uma ABC se você quer garantir um contrato de API:
 "Cara, você tem que implementar isso se quiser me chamar," como costuma dizer o revisor técnico Lennart Regebro.
 Isso é especialmente útil em sistemas com arquitetura plug-in.
-Fora das frameworks, duck typing é muitas vezes mais simples e flexível que verificações de tipo.
+Fora dos frameworks, duck typing é muitas vezes mais simples e flexível que verificações de tipo.
 
 Por fim, em seu ensaio Alex reforça mais de uma vez a necessidade de coibir a criação de ABCs.
 Uso excessivo de ABCs imporia cerimônia a uma linguagem que se tornou popular por ser prática e pragmática.

capitulos/cap14.adoc

@@ -863,7 +863,7 @@ Go é uma das mais bem sucedidas linguagens criadas no século 21. Ela não incl
 Em Go é possível definir interfaces, que são verificadas pelo compilador usando tipagem estrutural, também conhecida como((("static duck typing"))) _duck typing estática_—algo muito similar ao que temos com os tipos protocolo desde o Python 3.8. Essa linguagem também tem uma sintaxe especial para a criação de tipos e interfaces por composição, mas não há suporte a herança—nem entre interfaces.
 
 Então talvez o melhor conselho sobre herança seja: evite-a se puder.
-Mas, frequentemente, não temos essa opção: as frameworks que usamos nos impõe suas escolhas de design.
+Mas, frequentemente, não temos essa opção: os frameworks que usamos nos impõe suas escolhas de design.
 
 [[inheritance_further_reading]]
 === Leitura complementar

capitulos/cap19.adoc

@@ -1148,8 +1148,8 @@ o servidor de aplicação lida de forma transparente com a concorrência.
 ====
 A WSGI((("Asynchronous Server Gateway Interface (ASGI)")))((("servers", "Asynchronous Server Gateway Interface (ASGI)"))) é uma API síncrona. Ela não suporta corrotinas com `async/await`—a forma mais eficiente de implementar WebSockets or long pooling de HTTP em Python.
 A https://fpy.li/19-46[especificação da ASGI] é a sucessora da WSGI,
-projetada para frameworks Python assíncronas para programação web, tais como _aiohttp_, _Sanic_, _FastAPI_, etc.,
-bem como _Django_ e _Flask_, que estão gradativamente acrescentando funcionalidade assíncrona.
+projetada para frameworks Python assíncronos para programação web, tais como _aiohttp_, _Sanic_, _FastAPI_, etc.,
+bem como _Django_ e _Flask_, que estão gradativamente acrescentando funcionalidades assíncronas.
 ====
 
 Agora vamos examinar outra forma de evitar a GIL para obter um melhor desempenho em aplicações Python de servidor.

capitulos/cap21.adoc

@@ -106,7 +106,7 @@ Geradora assíncrona::
 O((("@asyncio.coroutine decorator"))) decorador `@asyncio.coroutine` para corrotinas clássicas e corrotinas baseadas em gerador foi descontinuado no Python 3.8, e está previsto para ser removido no Python 3.11, de acordo com o https://fpy.li/21-2[Issue 43216].
 Por outro lado, `@types.coroutine` deve continuar existindo, como se vê aqui:
 https://fpy.li/21-3[Issue 36921].
-Esse decorador não é mais suportado pelo _asyncio_, mas é usado em código interno nas frameworks assíncronas _Curio_ e _Trio_.
+Esse decorador não é mais suportado pelo _asyncio_, mas é usado em código interno nos frameworks assíncronos _Curio_ e _Trio_.
 ====
 
 
@@ -816,7 +816,7 @@ Veja o artigo https://pt.wikipedia.org/wiki/Listas_invertidas["Listas Invertidas
 ==== Um serviço web com FastAPI
 
 Escrevi((("FastAPI framework", id="fastapi21"))) o próximo exemplo—_web_mojifinder.py_—usando a https://fpy.li/21-28[_FastAPI_]:
-uma das frameworks ASGI de desenvolvimento Web do Python, mencionada na <<asgi_note>>.
+uma dos frameworks ASGI de desenvolvimento Web do Python, mencionada na <<asgi_note>>.
 A <<web_mojifinder_result>> é uma captura de tela da interface de usuário.
 É uma aplicação muito simples, de uma página só (SPA, Single Page Application): após o download inicial do HTML, a interface é atualizada via Javascript no cliente, em comunicação com o servidor.