vol2: preparação

Author: ramalho

links/FPY.LI.htaccess

@@ -1073,7 +1073,10 @@ RedirectTemp /24-27 https://docs.python.org/3/library/functools.html#functools.t
 RedirectTemp /24-28 https://www.python.org/download/releases/2.2.3/descrintro/
 RedirectTemp /24-29 https://github.com/lihaoyi/macropy
 RedirectTemp /24-30 https://people.eecs.berkeley.edu/~bh/ss-toc2.html
-# content of short.htaccess file created and managed by short.py
+
+# chapters
+RedirectTemp /7    https://pythonfluente.com/2/#ch_func_objects
+RedirectTemp /8    https://pythonfluente.com/2/#ch_type_hints_def
 
 # appended 2025-05-23 15:12:13
 RedirectTemp /22    https://pythonfluente.com/2/#pattern_matching_case_study_sec

online/cap10.adoc

@@ -258,7 +258,7 @@ include::../code/10-dp-1class-func/strategy.py[tags=STRATEGY_TESTS]
 <3> Uma função de promoção diferente é usada aqui e no teste seguinte.
 
 
-Observe os textos explicativos do <<ex_strategy_tests>>&mdash;não há necessidade
+Observe os textos explicativos do <<ex_strategy_tests>>: não há necessidade
 de instanciar um novo objeto `promotion` com cada novo pedido: as funções já
 estão disponíveis para serem usadas.
 

online/cap12.adoc

@@ -75,7 +75,9 @@ Quando um `Vector` tem mais de seis componentes, a string produzida por `repr()`
 `\...`, como visto na última linha do <<ex_vector_demo>>. Isso é fundamental para qualquer tipo de coleção que possa conter um número grande de itens, pois `repr` é usado na depuração—e você não quer que um único objeto grande ocupe milhares de linhas em seu console ou arquivo de log. Use o módulo `reprlib` para produzir representações de tamanho limitado, como no <<ex_vector_v1>>. O módulo `reprlib` se chamava `repr` no Python 2.7.
 ====
 
-O <<ex_vector_v1>> lista a implementação de nossa primeira versão de `Vector` (esse exemplo usa como base o código mostrado no pass:[<a data-type="xref" href="#ex_vector2d_v0" data-xrefstyle="select: labelnumber">#ex_vector2d_v0</a>] e no pass:[<a data-type="xref" href="#ex_vector2d_v1" data-xrefstyle="select: labelnumber">#ex_vector2d_v1</a>] do <<ch_pythonic_obj>>).
+O <<ex_vector_v1>> lista a implementação de nossa primeira versão de `Vector`
+(esse exemplo usa como base o código mostrado no <<ex_vector2d_v0>> e
+<<ex_vector2d_v1>> do <<ch_pythonic_obj>>).
 
 [[ex_vector_v1]]
 .vector_v1.py: derived from vector2d_v1.py
@@ -520,13 +522,12 @@ class Vector:
     # more lines omitted...
 ----
 ====
-[role="pagebreak-before less_space"]
 <1> Importa `functools` para usar `reduce`.
 <2> Importa `operator` para usar `xor`.
 <3> Não há mudanças em `+__eq__+`; listei-o aqui porque é uma boa prática manter `+__eq__+` e
 `+__hash__+` próximos no código-fonte, pois eles precisam trabalhar juntos.
 <4> Cria uma expressão geradora para computar sob demanda o _hash_ de cada componente.
-<5> Alimenta `reduce` com `hashes` e a função `xor`, para computar o código _hash_ agregado; o terceiro argumento, `0`, é o inicializador (veja o próximo aviso).
+<5> Alimenta `reduce` com `hashes` e a função `xor`, para computar o código _hash_ agregado; o terceiro argumento, `0`, é o inicializador (veja o aviso a seguir).
 
 [WARNING]
 ====
@@ -585,14 +586,22 @@ Uma forma melhor de comparar um `Vector` com outro `Vector` ou iterável seria o
         return True  # <4>
 ----
 ====
-<1> Se as `len` dos objetos são diferentes, eles não são iguais.
-<2> `zip` produz um gerador de tuplas criadas a partir dos itens em cada argumento iterável. Veja a caixa <<zip_box>>, se `zip` for novidade para você. Em pass:[<img src="callouts/1.png" alt="1"/>], a comparação com `len` é necessária porque `zip` para de produzir valores sem qualquer aviso quando uma das fontes de entrada se exaure.
+<1> Se as `len` dos objetos são diferentes, eles não são iguais. Este teste é importante porque o `zip` encerra a iteração
+assim que o primeiro argumento é consumido.
+<2> `zip` produz um gerador de tuplas criadas a partir dos itens em cada argumento iterável. Veja a caixa <<zip_box>>, se `zip` for novidade para você.
 <3> Sai assim que dois componentes sejam diferentes, devolvendo `False`.
 <4> Caso contrário, os objetos são iguais.
 
 [TIP]
 ====
-O((("zip() function")))((("functions", "zip() function"))) nome da função `zip` vem de zíper, pois esse objeto físico funciona engatando pares de dentes tomados dos dois lados do zíper, uma boa analogia visual para o que faz `zip(left, right)`. Nenhuma relação com arquivos comprimidos.
+O((("zip() function")))((("functions", "zip() function"))) nome da função `zip` vem de zíper,
+pois esse objeto físico funciona engatando pares de dentes a partir de duas sequências,
+uma boa analogia visual para o que faz `zip(esquerda, direita)`.
+Nenhuma relação com arquivos comprimidos. Por padrão, `zip` para de gerar tuplas assim que um de seus argumentos
+é consumido até o fim, e ele não levanta uma exceção, a menos que o argumento `strict=True` for passado.
+Esse argumento foi introduzido no Python 3.10, mas para preservar a compatibilidade,
+o default é `strict=False`.
+Isto pode causar falhas silenciosas quando um iterável termina antes dos demais.
 ====
 
 O <<ex_eq_loop>> é eficiente, mas a função `all` pode produzir a mesma computação de um agregado do loop `for` em apenas uma linha:
@@ -751,7 +760,13 @@ O último aperfeiçoamento a `Vector` foi reimplementar o método `+__format__+`
 
 Como fizemos no <<ch_pythonic_obj>>, muitas vezes aqui olhamos como os objetos padrão de Python se comportam, para emulá-los e dar a `Vector` uma aparência "pythônica".
 
-No <<ch_op_overload>> vamos implemenar vários operadores infixos em `Vector`. A matemática será mais simples que aquela no método `angle()` daqui, mas explorar como os operadores infixos funcionam no Python é uma grande lição sobre design orientado a objetos. Mas antes de chegar à sobrecarga de operadores, vamos parar um pouco de trabalhar com uma única classe e olhar para a organização de múltiplas classes com interfaces e herança, os assuntos dos capítulos pass:[<a data-type="xref" href="#ch_ifaces_prot_abc" data-xrefstyle="select: labelnumber">#ch_ifaces_prot_abc</a>] e pass:[<a data-type="xref" href="ch_inheritance" data-xrefstyle="select: labelnumber">ch_inheritance</a>].
+No <<ch_op_overload>> vamos implemenar vários operadores infixos em `Vector`.
+A matemática será mais simples que aquela no método `angle()` daqui,
+mas explorar como os operadores infixos funcionam no Python
+é uma grande lição sobre design orientado a objetos.
+Mas antes de chegar à sobrecarga de operadores em uma classe,
+vamos estudar a organização de várias classes com interfaces e herança,
+os assuntos dos capítulos <<ch_ifaces_prot_abc>> e <<ch_inheritance>>.
 
 
 === Para saber mais

online/cap13.adoc

@@ -81,7 +81,7 @@ Este((("interfaces", "significant changes to")))((("protocols", "significant cha
 * <<two_kinds_protocols_sec>> explica as semelhanças e diferenças entre protocolos dinâmicos e estáticos.
 * <<defensive_duck_prog_sec>> praticamente reproduz o conteúdo da primeira edição, mas foi atualizada e agora tem um título de seção que enfatiza sua importância.
 * <<static_protocols_sec>> é toda nova. Ela se apoia na apresentação inicial em <<protocols_in_fn_sec>> (<<ch_type_hints_def>>).
-* Os diagramas de classe de `collections.abc` nas Figuras pass:[<a href="#sequence_uml_repeat" data-type="xref" data-xrefstyle="select:labelnumber">#sequence_uml_repeat</a>], pass:[<a href="#mutablesequence_uml" data-type="xref" data-xrefstyle="select:labelnumber">#mutablesequence_uml</a>], and pass:[<a href="#collections_uml" data-type="xref" data-xrefstyle="select:labelnumber">#collections_uml</a>] foram atualizados para incluir a `Collection` ABC, de Python 3.6.
+* Os diagramas de classe de `collections.abc` neste capítulo foram atualizados para incluir a `Collection` ABC, do Python 3.6.
 
 A primeira edição de _Python Fluente_ tinha uma seção encorajando o uso das ABCs  `numbers` para goose typing.
 Na <<numbers_abc_proto_sec>> eu explico porque, em vez disso, você deve usar protocolos numéricos estáticos do módulo `typing` se você planeja usar checadores de tipos estáticos, ou checagem durante a execução no estilo da goose typing.
@@ -485,7 +485,13 @@ class Lottery:
     def draw(self): ...
 ----
 
-Obviamente, a mera existência de um método chamado `draw`, chamado sem argumentos, [.keep-together]#está longe# de ser suficiente para garantir que dois objetos `x` e `y`, da forma como `x.draw()` e `y.draw()` podem ser chamados, são de qualquer forma intercambiáveis ou abstratamente pass:[equivalentes &mdash;<span class="keep-together"> nada</span>] sobre a similaridade da semântica resultante de tais chamadas pode ser inferido. Na verdade, é necessário um programador inteligente para, de alguma forma, _assegurar_ positivamente que tal equivalência é verdadeira em algum nível.
+Obviamente, a mera existência de um método chamado `draw`, sem parâmetros,
+não é suficiente para garantir que dois objetos `x` e `y`,
+que aceitem as invocações `x.draw()` e `y.draw()`,
+são de qualquer forma intercambiáveis ou abstratamente equivalentes—nada
+pode ser inferido sobre a similaridade da semântica resultante de tais chamadas.
+Na verdade, é necessário um programador inteligente para,
+de alguma forma, _assegurar_ positivamente que tal equivalência é verdadeira em algum nível.
 
 Em biologia (e outras disciplinas), este problema levou à emergência (e, em muitas facetas, à dominância) de uma abordagem alternativa à _fenética_, conhecida como ((("cladistics"))) __cladística__ — que baseia as escolhas taxinômicas em características herdadas de ancestrais comuns em vez daquelas que evoluíram de forma independente (o sequenciamento de DNA cada vez mais barato e rápido vem tornando a cladística bastante prática em mais casos).
 
@@ -672,8 +678,7 @@ Essa ABC não tem nenhum método próprio, mas foi acrescentada no Python 3.6 pa
 `Sequence`, `Mapping`, `Set`::
 Esses são os principais tipos de coleções imutáveis, e cada um tem uma subclasse mutável.
 Um diagrama detalhado de `MutableSequence` é apresentado em <<mutablesequence_uml>>;
-para `MutableMapping` e `MutableSet`, veja as Figuras pass:[<a data-type="xref" href="#mapping_uml" data-xrefstyle="select: labelnumber">#mapping_uml</a>] e
-pass:[<a data-type="xref" href="#set_uml" data-xrefstyle="select: labelnumber">#set_uml</a>] em <<ch_dicts_sets>>.
+para `MutableMapping` e `MutableSet`, veja a <<mapping_uml>> e a <<set_uml>> em <<ch_dicts_sets>>.
 
 `MappingView`::
 No Python 3, os objetos retornados pelos métodos de mapeamentos `.items()`, `.keys()`, e `.values()`
@@ -756,11 +761,14 @@ Os métodos concretos são:
 `.inspect()`:: Retorna uma `tuple` construída a partir dos itens atualmente no container, sem modificar o conteúdo (a ordem interna não é preservada).
 
 A <<tombola_uml>> mostra a ABC `Tombola` e três implementações concretas.
+Vale notar que _registered_ (registarada) e _virtual subclass_ (subclasse virtual)
+não são termos da UML padrão, mas representam uma relação de classe específica de Python,
+como veremos na <<virtual_subclass_sec>>.
 
 [role="width-80"]
 [[tombola_uml]]
-
-.Diagrama UML para uma ABC e três subclasses. O nome da ABC `Tombola` e de seus métodos abstratos estão escritos em _itálico_, segundo as convenções da UML. A seta tracejada é usada para implementações de interface - as estou usando aqui para mostrar que `TomboList` implementa não apenas a interface `Tombola`, mas também está registrada como uma _subclasse virtual_ de `Tombola` - como veremos mais tarde nesse capítulo.pass:[<span data-type="footnote"><span class="roman">«registrada» and «subclasse virtual» não são termos da UML padrão. Estão sendo usados para representar uma relação de classe específica de Python.</span></span>]
+.Diagrama UML para uma ABC e três subclasses. O nome da ABC `Tombola` e de seus métodos abstratos estão escritos em _itálico_, segundo as convenções da UML. A seta tracejada indica que `TomboList` implementa a interface `Tombola`, e também está registrada como _subclasse virtual_.
+`TomboList` também está registrada como uma _subclasse virtual_ de `Tombola`.
 image::../images/flpy_1305.png[UML for Tombola]
 
 O <<ex_tombola_abc>> mostra a definição da ABC `Tombola`.
@@ -1861,13 +1869,16 @@ Beazley and Jones's pass:[<em><a class="orm:hideurl" href="https://fpy.li/pycook
 tem uma seção sobre como definir uma ABC (Recipe 8.12).
 O livro foi escrito antes de Python 3.4,
 então eles não usam a atual sintaxe preferida para declarar ABCs, criar uma subclasse de `abc.ABC`
-(em vez disso, eles usam a palavra-chave `metaclass`, da qual  só vamos precisar mesmo em<<ch_class_metaprog>>).
+(em vez disso, eles usam a palavra-chave `metaclass`, da qual só vamos precisar mesmo em<<ch_class_metaprog>>).
 Tirando esse pequeno detalhe, a receita cobre os principais recursos das ABCs muito bem.
 
 _The Python Standard Library by Example_ by Doug Hellmann (Addison-Wesley),
 tem um capítulo sobre o módulo `abc`.
-Ele também esta disponível na web, no excelente site do Doug https://fpy.li/13-51[_PyMOTW_&mdash;Python Module of the Week] (EN).
-Hellmann também usa a declaração de ABC no estilo antigo:`PluginBase(metaclass=abc.ABCMeta)` em vez do mais simples `PluginBase(abc.ABC)`, disponível desde o Python 3.4.
+Ele também esta disponível na web, em
+https://fpy.li/13-51[_PyMOTW—Python Module of the Week_].
+Hellmann usa a declaração de ABC no estilo
+antigo:`PluginBase(metaclass=abc.ABCMeta)`
+em vez de `PluginBase(abc.ABC)`, suportada desde o Python 3.4.
 
 Quando usamos ABCs, herança múltipla não é apenas comum mas praticamente inevitável,
 porque cada uma das ABCs fundamentais de coleções (`Sequence`, `Mapping`, `Set`)

vol1/vol1.adoc

@@ -1,4 +1,4 @@
-= Python Fluente:  2ª edição, volume 1: dados e funções
+= Python Fluente:  2ª edição, volume 1: Dados e Funções
 :doctype: book
 :media: prepress
 :hide-uri-scheme:

vol1/xilo_calango_tc_flat.png

@@ -0,0 +1 @@
+vol2.pdf

vol2/.gitignore

@@ -0,0 +1,46 @@
+[colophon%discrete%notitle%nonfacing,toclevels=0]
+= Copyright
+
+Tradução em português autorizada da edição em inglês da obra _Fluent Python, 2nd Edition_ ISBN 978-1-492-05635-5
+© 2022 Luciano Ramalho.
+Esta tradução é publicada e vendida com a permissão da O'Reilly Media, Inc.,
+detentora dos direitos para publicação e venda desta obra.
+
+© 2025 Luciano Ramalho. +
+_Python Fluente, 2a edição_ está publicado sob a licença
+_Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional_ 
+«CC BY-NC-SA 4.0» [.small]#[fpy.li/ccby]#. +
+O autor mantém uma versão online em https://PythonFluente.com.
+
+Autor: Luciano Ramalho +
+Título: Python Fluente, 2ª edição, volume 2: classes e protocolos +
+Primeira edição: 2015 +
+Edição atual: setembro/2025 +
+{revisao}ª revisão: `pyfl-vol2-rev{revisao}.pdf`
+
+Tradução: Paulo Candido de Oliveira Filho
+
+Ilustração de capa: Thiago Castor (xilogravura "Calango")  +
+Design de Capa: Luciano Ramalho, Zander Catta Preta @ Z•Edições +
+Design de Miolo: Luciano Ramalho, com Aciidoctor
+
+Publisher: Heinar Maracy @ Z•Edições
+
+----
+Dados Internacionais de Catalogação na Publicação (CIP)
+Câmara Brasileira do Livro, SP, Brasil
+
+        Ramalho, Luciano.
+
+        Python Fluente, 2a edição, volume 2: classes e protocolos /
+        Luciano Ramalho - São Paulo, SP - Z.Edições, 2025.
+        402 f.; il.; 17 cm × 24 cm
+
+        ISBN: XXX-XX-XXXXXX-X-X
+        1.Informática. 2.Linguagem de Programação. 3.Python.
+        4.Curso de Programação Python.
+
+            I. Título
+            
+                                                            CDD 004.43
+----

vol2/Copyright.adoc

@@ -0,0 +1,62 @@
+= Python Fluente: 2ª edição, volume 2: Classes e Protocolos
+:doctype: book
+:media: prepress
+:hide-uri-scheme:
+:pdf-page-size: [17cm, 24cm]
+:source-highlighter: rouge
+:author: Luciano Ramalho
+:lang: pt_BR
+:language: asciidoctor
+:xrefstyle: short
+:sectnums:
+:sectnumlevels: 4
+:sectlinks:
+:data-uri:
+:!chapter-signifier:
+include::../print/attrib-print-pt-br.adoc[]
+:toclevels: 2
+:toc: macro
+:revisao: 8
+
+include::Copyright.adoc[]
+
+[dedication%notitle%discrete,toclevels=0]
+= Dedicatória
+__Para Marta, com todo o meu amor.__
+
+toc::[]
+
+= Parte II.b: Funções como objetos
+
+[NOTE]
+====
+Esta versão impressa do _Python Fluente, segunda edição_
+foi publicada em três volumes, com oito capítulos por volume.
+
+A Parte II ficou dividida entre os Volumes 1 e 2.
+
+Os capítulos 9 e 10 estão neste Volume 2.
+
+A Parte II.a está no Volume 1, e também na Web:
+
+«Capítulo 7—Funções como objetos de primeira classe» [.small]#[fpy.li/7]#
+
+«Capítulo 8—Padrões de projeto com funções» [.small]#[fpy.li/8]#
+
+
+====
+
+include::../online/cap09.adoc[]
+include::../online/cap10.adoc[]
+
+[[data_structures_part]]
+= Parte III: Classes e protocolos
+:sectnums:
+
+include::../online/cap11.adoc[]
+include::../online/cap12.adoc[]
+include::../online/cap13.adoc[]
+include::../online/cap14.adoc[]
+include::../online/cap15.adoc[]
+include::../online/cap16.adoc[]
+