Desde Python 2.7, a sintaxe das listcomps e genexps foi adaptada para compreensões de dict (e também compreensões de set, que veremos em breve). Uma dictcomp (compreensão de dict) cria uma instância de dict, recebendo pares key:value de qualquer iterável. O Exemplos de compreensões de dict mostra o uso de compreensões de dict para criar dois dicionários a partir de uma mesma lista de tuplas.

1. Um iterável de pares chave-valor como dial_codes pode ser passado diretamente para o construtor de dict, mas…​

2. …​aqui permutamos os pares: country é a chave, e code é o valor.

3. Ordenando country_dial por nome, revertendo novamente os pares, colocando os valores em maiúsculas e filtrando os itens com code < 70.

Se você já usa listcomps, as dictcomps são um próximo passo natural. Caso contrário, a propagação da sintaxe de compreensão mostra que agora é mais valioso que nunca se tornar fluente nessa técnica.

A PEP 448—Additional Unpacking Generalizations (Generalizações de Desempacotamento Adicionais) melhorou o suporte ao desempacotamento de mapeamentos de duas formas, desde o Python 3.5.

Primeiro, podemos aplicar ** a mais de um argumento em uma chamada de função. Isso funciona quando todas as chaves são strings e únicas, para todos os argumentos (porque argumentos nomeados duplicados são proibidos):

Em segundo lugar, ** pode ser usado dentro de um literal dict—também múltiplas vezes:

Nesse caso, chaves duplicadas são permitidas. Cada ocorrência sobrescreve ocorrências anteriores—observe o valor mapeado para x no exemplo.

Essa sintaxe também pode ser usada para mesclar mapas, mas isso pode ser feito de outras formas. Siga comigo.

Desde a versão 3.9, Python suporta o uso de | e |= para mesclar mapeamentos. Isso faz todo sentido, já que estes são também os operadores de união de conjuntos.

O operador | cria um novo mapeamento:

O tipo do novo mapeamento normalmente será o mesmo do operando da esquerda—no exemplo, d1—mas ele pode ser do tipo do segundo operando se tipos definidos pelo usuário estiverem envolvidos na operação, dependendo das regras de sobrecarga de operadores, que exploraremos no [ch_op_overload].

Para atualizar mapeamentos existentes internamente, use |=. Retomando o exemplo anterior, ali d1 não foi modificado. Mas aqui sim:

Agora vamos ver como o casamento de padrões se aplica aos mapeamentos.

Aqui está parte da definição de hashable, adaptado do Glossário de Python:

Um objeto é hashable se tem um código de hash que nunca muda durante seu ciclo de vida (precisa ter um método __hash__) e pode ser comparado com outros objetos (precisa ter um método __eq__). Objetos hashable que são comparados como iguais devem ter o mesmo código de hash.^[2]

Tipos numéricos e os tipos planos imutáveis str e bytes são todos hashable. Tipos contêineres são hashable se forem imutáveis e se todos os objetos por eles contidos forem também hashable. Um frozenset é sempre hashable, pois todos os elementos que ele contém devem ser, por definição, hashable. Uma tuple é hashable apenas se todos os seus itens também forem. Observe as tuplas tt, tl, e tf:

O código de hash de um objeto pode ser diferente dependendo da versão de Python, da arquitetura da máquina, e pelo sal acrescentado ao cálculo do hash por razões de segurança.^[3] O código de hash de um objeto corretamente implementado tem a garantia de ser constante apenas dentro de um processo Python.

Tipos definidos pelo usuário são hashble por default, pois seu código de hash é seu id(), e o método __eq__() herdado da classe objetct apenas compara os IDs dos objetos. Se um objeto implementar seu próprio __eq__(), que leve em consideração seu estado interno, ele será hashable apenas se seu __hash__() sempre devolver o mesmo código de hash. Na prática, isso exige que __eq__() e __hash__() levem em conta apenas atributos de instância que nunca mudem durante a vida do objeto.

Vamos agora revisar a API dos tipos de mapeamento mais comumente usado no Python: dict, defaultdict, e OrderedDict.

A API básica para mapeamentos é bem completa. A Métodos do tipos de mapeamento dict, collections.defaultdict, e collections.OrderedDict (métodos comuns de object omitidos por concisão); argumentos opcionais então entre […] mostra os métodos implementados por dict e pelas variantes mais usadas: defaultdict e OrderedDict, ambas classes definidas no módulo collections.

A forma como d.update(m) lida com seu primeiro argumento, m, é um excelente exemplo de duck typing (tipagem pato): ele primeiro verifica se m tem um método keys e, em caso afirmativo, assume que m é um mapeamento. Caso contrário, update() reverte para uma iteração sobre m, presumindo que seus item são pares (chave, valor). O construtor da maioria dos mapeamentos de Python usa internamente a lógica de update(), o que quer dizer que eles podem ser inicializados por outros mapeamentos ou a partir de qualquer objeto iterável que produza pares (chave, valor).

Um método sutil dos mapeamentos é setdefault(). Ele evita buscas redundantes de chaves quando precisamos atualizar o valor em um item no mesmo lugar. A próxima seção mostra como ele pode ser usado.

Alinhada à filosofia de falhar rápido de Python, a consulta a um dict com d[k] gera um erro quando k não é uma chave existente. Pythonistas sabem que d.get(k, default) é uma alternativa a d[k] quando receber um valor default é mais conveniente que tratar um KeyError. Entretanto, se você está buscando um valor mutável e quer atualizá-lo, há um jeito melhor.

Considere um script para indexar texto, produzindo um mapeamento no qual cada chave é uma palavra, e o valor é uma lista das posições onde aquela palavra ocorre, como mostrado no Saída parcial do [index0_ex] processando o texto "Zen of Python"; cada linha mostra uma palavra e uma lista de ocorrências na forma de pares (line_number, column_number) (número da linha, número da coluna)..

O index0.py usa dict.get para obter e atualizar uma lista de ocorrências de palavras de um índice (uma solução melhor é apresentada no [index_ex]) é um script aquém do ideal, para mostrar um caso onde dict.get não é a melhor maneira de lidar com uma chave ausente. Ele foi adaptado de um exemplo de Alex Martelli.^[7]

1. Obtém a lista de ocorrências de word, ou [] se a palavra não for encontrada.

2. Acrescenta uma nova localização a occurrences.

3. Coloca a occurrences modificada no dict index; isso exige uma segunda busca em index.

4. Não estou chamando str.upper no argumento key= de sorted, apenas passando uma referência àquele método, para que a função sorted possa usá-lo para normalizar as palavras antes de ordená-las.^[8]

As três linhas tratando de occurrences no index0.py usa dict.get para obter e atualizar uma lista de ocorrências de palavras de um índice (uma solução melhor é apresentada no [index_ex]) podem ser substituídas por uma única linha usando dict.setdefault. O index.py usa dict.setdefault para obter e atualizar uma lista de ocorrências de uma palavra em uma única linha de código; compare com o [index0_ex] fica mais próximo do código apresentado por Alex Martelli.

1. Obtém a lista de ocorrências de word, ou a define como [], se não for encontrada; setdefault devolve o valor, então ele pode ser atualizado sem uma segunda busca.

Em outras palavras, o resultado final desta linha…​

…​é o mesmo que executar…​

…​exceto que este último trecho de código executa pelo menos duas buscas por key—três se a chave não for encontrada—enquanto setdefault faz tudo isso com uma única busca.

Uma questão relacionada, o tratamento de chaves ausentes em qualquer busca (e não apenas para inserção de valores), é o assunto da próxima seção.

Uma instância de collections.defaultdict cria itens com um valor default sob demanda, sempre que uma chave ausente é buscada usando a sintaxe d[k]. O index_default.py: usando um defaultdict em vez do método setdefault usa defaultdict para fornecer outra solução elegante para o índice de palavras do index.py usa dict.setdefault para obter e atualizar uma lista de ocorrências de uma palavra em uma única linha de código; compare com o [index0_ex].

Funciona assim: ao instanciar um defaultdict, você fornece um invocável que produz um valor default sempre que __getitem__ recebe uma chave inexistente como argumento.

Por exemplo, dado um defaultdict criado por dd = defaultdict(list), se 'new-key' não estiver em dd, a expressão dd['new-key'] segue os seguintes passos:

1. Chama list()` para criar uma nova lista.

2. Insere a lista em dd usando 'new-key' como chave.

3. Devolve uma referência para aquela lista.

O invocável que produz os valores default é mantido em um atributo de instância chamado default_factory.

1. Cria um defaultdict com o construtor de list como default_factory.

2. Se word não está inicialmente no index, o default_factory é chamado para produzir o valor ausente, que neste caso é uma list vazia, que então é atribuída a index[word] e devolvida, de forma que a operação .append(location) é sempre bem sucedida.

Se nenhum default_factory é fornecido, o KeyError usual é gerado para chaves ausente.

O mecanismo que faz defaultdict funcionar, chamando default_factory, é o método especial __missing__, apresentado a seguir.

Por trás da forma como os mapeamentos lidam com chaves ausentes está o método muito apropriadamente chamado __missing__.^[9] Esse método não é definido na classe base dict, mas dict está ciente de sua possibilidade: se você criar uma subclasse de dict e incluir um método __missing__, o dict.__getitem__ padrão vai chamar seu método sempre que uma chave não for encontrada, em vez de gerar um KeyError.

Suponha que você queira um mapeamento onde as chaves são convertidas para str quando são procuradas. Um caso de uso concreto seria uma biblioteca para dispositivos IoT (Internet of Things, Internet das Coisas)^[10], onde uma placa programável com portas genéricas programáveis (por exemplo, uma Raspberry Pi ou uma Arduino) é representada por uma classe "Placa" com um atributo minha_placa.portas, que é uma mapeamento dos identificadores das portas físicas para objetos de software portas. O identificador da porta física pode ser um número ou uma string como "A0" ou "P9_12". Por consistência, é desejável que todas as chaves em placa.portas seja strings, mas também é conveniente buscar uma porta por número, como em meu-arduino.porta[13], para evitar que iniciantes tropecem quando quiserem fazer piscar o LED na porta 13 de seus Arduinos. O Ao buscar por uma chave não-string, StrKeyDict0 a converte para str quando ela não é encontrada mostra como tal mapeamento funcionaria.

O StrKeyDict0 converte chaves não-string para string no momento da consulta (vejas os testes no [ex_strkeydict0_tests]) implementa a classe StrKeyDict0, que passa nos doctests acima.

1. StrKeyDict0 herda de dict.

2. Verifica se key já é uma str. Se é, e está ausente, gera um KeyError.

3. Cria uma str de key e a procura.

4. O método get delega para __getitem__ usando a notação self[key]; isso dá oportunidade para nosso __missing__ agir.

5. Se um KeyError foi gerado, __missing__ já falhou, então devolvemos o default.

6. Procura pela chave não-modificada (a instância pode conter chaves não-str), depois por uma str criada a partir da chave.

Considere por um momento o motivo do teste isinstance(key, str) ser necessário na implementação de __missing__.

Sem aquele teste, nosso método __missing__ funcionaria bem com qualquer chave k—str ou não—sempre que str(k) produzisse uma chave existente. Mas se str(k) não for uma chave existente, teríamos uma recursão infinita. Na última linha de __missing__, self[str(key)] chamaria __getitem__, passando aquela chave str, e __getitem__, por sua vez, chamaria __missing__ novamente.

O método __contains__ também é necessário para que o comportamento nesse exemplo seja consistente, pois a operação k in d o chama, mas o método herdado de dict não invoca __missing__ com chaves ausentes. Há um detalhe sutil em nossa implementação de __contains__: não verificamos a existência da chave da forma pythônica normal—k in d—porque str(key) in self chamaria __contains__ recursivamente. Evitamos isso procurando a chave explicitamente em self.keys().

Uma busca como k in my_dict.keys() é eficiente em Python 3 mesmo para mapeamentos muito grandes, porque dict.keys() devolve uma view, que é similar a um set, como veremos na Operações de conjuntos em views de dict. Entretanto, lembre-se de que k in my_dict faz o mesmo trabalho, e é mais rápido porque evita a busca nos atributos para encontrar o método .keys.

Eu tinha uma razão específica para usar self.keys() no método __contains__ do StrKeyDict0 converte chaves não-string para string no momento da consulta (vejas os testes no [ex_strkeydict0_tests]). A verificação da chave não-modificada key in self.keys() é necessária por correção, pois StrKeyDict0 não obriga todas as chaves no dicionário a serem do tipo str. Nosso único objetivo com esse exemplo simples foi fazer a busca "mais amigável", e não forçar tipos.

Considere os seguintes cenários, e como eles afetam a busca de chaves ausentes:

subclasse de dict

Uma subclasse de dict que implemente apenas __missing__ e nenhum outro método. Nesse caso, __missing__ pode ser chamado apenas em d[k], que usará o __getitem__ herdado de dict.

subclasse de collections.UserDict

Da mesma forma, uma subclasse de UserDict que implemente apenas __missing__ e nenhum outro método. O método get herdado de UserDict chama __getitem__. Isso significa que __missing__ pode ser chamado para tratar de consultas com d[k] e com d.get(k).

subclasse de abc.Mapping com o __getitem__ mais simples possível

Uma subclasse mínima de abc.Mapping, implementando __missing__ e os métodos abstratos obrigatórios, incluindo uma implementação de __getitem__ que não chama __missing__. O método __missing__ nunca é acionado nessa classe.

subclasse de abc.Mapping com __getitem__ chamando __missing__

Uma subclasse mínima de abc.Mapping, implementando __missing__ e os métodos abstratos obrigatórios, incluindo uma implementação de __getitem__ que chama __missing__. O método __missing__ é acionado nessa classe para consultas por chaves ausentes feitas com d[k], d.get(k), e k in d.

Veja missing.py no repositório de exemplos de código para demonstrações dos cenários descritos acima.

Os quatro cenários que acabo de descrever supõem implementações mínimas. Se a sua subclasse implementa __getitem__, get, e __contains__, então você pode ou não fazer tais métodos usarem __missing__, dependendo de suas necessidades. O ponto aqui é mostrar que é preciso ter cuidado ao criar subclasses dos mapeamentos da biblioteca padrão para usar __missing__, porque as classes base suportam comportamentos default diferentes. Não se esqueça que o comportamento de setdefault e update também é afetado pela consulta de chaves. E por fim, dependendo da lógica de seu __missing__, pode ser necessário implementar uma lógica especial em __setitem__, para evitar inconsistências ou comportamentos surpreendentes. Veremos um exemplo disso na Criando subclasses de UserDict em vez de dict.

Até aqui tratamos dos tipos de mapeamentos dict e defaultdict, mas a biblioteca padrão traz outras implementações de mapeamentos, que discutiremos a seguir.

Agora que o dict embutido também mantém as chaves ordenadas (desde o Python 3.6), o motivo mais comum para usar OrderedDict é escrever código compatível com versões anteriores de Python. Dito isso, a documentação lista algumas diferenças entre dict e OrderedDict que ainda persistem e que cito aqui:

• A operação de igualdade para OrderedDict verifica a igualdade da ordenação.

• O método popitem() de OrderedDict tem uma assinatura diferente, que aceita um argumento opcional especificando qual item será devolvido.

• OrderedDict tem um método move_to_end(), que reposiciona de um elemento para uma ponta do dicionário de forma eficiente.

• O dict comum foi projetado para ser muito bom nas operações de mapeamento. Preservar a ordem de inserção era uma preocupação secundária.

• OrderedDict foi projetado para ser bom em operações de reordenamento. Eficiência espacial, velocidade de iteração e o desempenho de operações de atualização eram preocupações secundárias.

• Em termos do algoritmo, um OrderedDict lida melhor que um dict com operações frequentes de reordenamento. Isso o torna adequado para monitorar acessos recentes (em um cache LRU^[11], por exemplo).

Uma instância de ChainMap mantém uma lista de mapeamentos que podem ser consultados como se fossem um mapeamento único. A busca é realizada em cada mapa incluído, na ordem em que eles aparecem na chamada ao construtor, e é bem sucedida assim que a chave é encontrada em um daqueles mapeamentos. Por exemplo:

A instância de ChainMap não cria cópias dos mapeamentos, mantém referências para eles. Atualizações ou inserções a um ChainMap afetam apenas o primeiro mapeamento passado. Continuando do exemplo anterior:

Um ChainMap é útil na implementação de linguagens com escopos aninhados, onde cada mapeamento representa um contexto de escopo, desde o escopo aninhado mais interno até o mais externo. A seção "Objetos ChainMap", na documentação de collections, apresenta vários exemplos do uso de Chainmap, incluindo esse trecho inspirado nas regras básicas de consulta de variáveis no Python:

A [lispy_environ_sec] explica uma subclasse de ChainMap usada para implementar um interpretador parcial da linguagem de programação Scheme.

Um mapeamento que mantém uma contagem para cada chave. Atualizar uma chave existente adiciona à sua contagem. Isso pode ser usado para contar instâncias de objetos hashable ou como um multiset (conjunto múltiplo), discutido adiante nessa seção. Counter implementa os operadores + e - para combinar contagens, e outros métodos úteis tal como o most_common([n]), que devolve uma lista ordenada de tuplas com os n itens mais comuns e suas contagens; veja a documentação.

Aqui temos um Counter usado para contar as letras em palavras:

Observe que as chaves 'b' e 'r' estão empatadas em terceiro lugar, mas ct.most_common(3) mostra apenas três contagens.

Para usar collections.Counter como um conjunto múltiplo, trate cada chave como um elemento de um conjunto, e a contagem será o número de ocorrências daquele elemento no conjunto.

O módulo shelve na biblioteca padrão fornece armazenamento persistente a um mapeamento de chaves em formato string para objetos Python serializados no formato binário pickle. O nome curioso, shelve, faz sentido quando você percebe que potes de pickle são armazenadas em prateleiras.^[12]

A função de módulo shelve.open devolve uma instância de shelve.Shelf—um banco de dados DBM simples de chave-valor, baseado no módulo dbm, com as seguintes características:

• shelve.Shelf é uma subclasse de abc.MutableMapping, então fornece os métodos essenciais esperados de um tipo mapeamento.

• Além disso, shelve.Shelf fornece alguns outros métodos de gerenciamento de E/S, como sync e close.

• Uma instância de Shelf é um gerenciador de contexto, então é possível usar um bloco with para garantir que ela seja fechada após o uso.

• Chaves e valores são salvos sempre que um novo valor é atribuído a uma chave.

• As chaves devem ser strings.

• Os valores devem ser objetos que o módulo pickle possa serializar.

A documentação para os módulos shelve, dbm (EN), e pickle traz mais detalhes e também algumas ressalvas.

As classes OrderedDict, ChainMap, Counter, e Shelf podem ser usadas diretamente, mas também podem ser customizadas por subclasses. UserDict, por outro lado, foi planejada apenas como uma classe base a ser estendida.

É melhor criar um novo tipo de mapeamento estendendo collections.UserDict em vez de dict. Percebemos isso quando tentamos estender nosso StrKeyDict0 do StrKeyDict0 converte chaves não-string para string no momento da consulta (vejas os testes no [ex_strkeydict0_tests]) para assegurar que qualquer chave adicionada ao mapeamento seja armazenada como str.

A principal razão pela qual é melhor criar uma subclasse de UserDict em vez de dict é que o tipo embutido tem alguns atalhos de implementação, que acabam nos obrigando a sobrescrever métodos que poderíamos apenas herdar de UserDict sem maiores problemas.^[13]

Observe que UserDict não herda de dict, mas usa uma composição: a classe tem uma instância interna de dict, chamada data, que mantém os itens propriamente ditos. Isso evita recursão indesejada quando escrevemos métodos especiais, como __setitem__, e simplifica a programação de __contains__, quando comparado com o StrKeyDict0 converte chaves não-string para string no momento da consulta (vejas os testes no [ex_strkeydict0_tests]).

Graças a UserDict, o StrKeyDict (StrKeyDict sempre converte chaves que não sejam strings para str na inserção, atualização e busca) é mais conciso que o StrKeyDict0 (StrKeyDict0 converte chaves não-string para string no momento da consulta (vejas os testes no [ex_strkeydict0_tests])), mais ainda faz melhor: ele armazena todas as chaves como str, evitando surpresas desagradáveis se a instância for criada ou atualizada com dados contendo chaves de outros tipos (que não string).

1. StrKeyDict estende UserDict.

2. __missing__ é exatamente igual ao do StrKeyDict0 converte chaves não-string para string no momento da consulta (vejas os testes no [ex_strkeydict0_tests]).

3. __contains__ é mais simples: podemos assumir que todas as chaves armazenadas são str, e podemos operar sobre self.data em vez de invocar self.keys(), como fizemos em StrKeyDict0.

4. __setitem__ converte qualquer key para uma str. Esse método é mais fácil de sobrescrever quando podemos delegar para o atributo self.data.

Como UserDict estende abc.MutableMapping, o restante dos métodos que fazem de StrKeyDict um mapeamento completo são herdados de UserDict, MutableMapping, ou Mapping. Estes últimos contém vários métodos concretos úteis, apesar de serem classes base abstratas (ABCs). Os seguinte métodos são dignos de nota:

MutableMapping.update

Esse método poderoso pode ser chamado diretamente, mas também é usado por __init__ para criar a instância a partir de outros mapeamentos, de iteráveis de pares (chave, valor), e de argumentos nomeados. Como usa self[chave] = valor para adicionar itens, ele termina por invocar nossa implementação de __setitem__.

Mapping.get

No StrKeyDict0 (StrKeyDict0 converte chaves não-string para string no momento da consulta (vejas os testes no [ex_strkeydict0_tests])), precisamos codificar nosso próprio get para devolver os mesmos resultados de __getitem__, mas no StrKeyDict sempre converte chaves que não sejam strings para str na inserção, atualização e busca herdamos Mapping.get, que é implementado exatamente como StrKeyDict0.get (consulte o código-fonte de Python).

Sabemos que existem tipos de sequências imutáveis, mas e mapeamentos imutáveis? Não existe um tipo real desses na biblioteca padrão, mas um substituto está disponível. É o que vem a seguir.

A sintaxe de literais set—{1}, {1, 2}, etc.—parece muito com a notação matemática, mas há uma importante exceção: não há notação literal para o set vazio, então precisamos nos lembrar de escrever set().

No Python 3, a representação padrão dos sets como strings sempre usa a notação {…}, exceto para o conjunto vazio:

A sintaxe do set literal, como {1, 2, 3}, é mais rápida e mais legível que uma chamada ao construtor (por exemplo, set([1, 2, 3])). Essa última forma é mais lenta porque, para avaliá-la, Python precisa buscar o nome set para obter seu construtor, daí criar uma lista e, finalmente, passá-la para o construtor. Por outro lado, para processar um literal como {1, 2, 3}, o Python roda um bytecode especializado, BUILD_SET.^[16]

Não há sintaxe especial para representar literais frozenset—eles só podem ser criados chamando seu construtor. Sua representação padrão como string no Python 3 se parece com uma chamada ao construtor de frozenset com um argumento set. Observe a saída no console:

E por falar em sintaxe, a ideia das listcomps foi adaptada para criar conjuntos também.

Compreensões de conjuntos (setcomps) apareceram há bastante tempo, no Python 2.7, junto com as dictcomps que vimos na Compreensões de dict. O Cria um conjunto de caracteres Latin-1 que tenham a palavra "SIGN" em seus nomes Unicode mostra procedimento.

1. Importa a função name de unicodedata para obter os nomes dos caracteres.

2. Cria um conjunto de caracteres com códigos entre 32 e 255 que contenham a palavra 'SIGN' em seus nomes.

A ordem da saída muda a cada processo Python, devido ao hash "salgado", mencionado na O que é hashable?.

Questões de sintaxe à parte, vamos considerar agora o comportamento dos conjuntos.

A Diagrama de classes UML simplificado para MutableSet e suas superclasses em collections.abc (nomes em itálico são classes e métodos abstratos; métodos de operadores reversos foram omitidos por concisão). dá uma visão geral dos métodos disponíveis em conjuntos mutáveis e imutáveis. Muitos deles são métodos especiais que sobrecarregam operadores, como & e >=. A Operações matemáticas com conjuntos: esses métodos produzem um novo conjunto ou atualizam o conjunto alvo internamente, se ele for mutável mostra os operadores matemáticos de conjuntos que tem operadores ou métodos correspondentes no Python. Note que alguns operadores e métodos realizam mudanças internas sobre o conjunto alvo (por exemplo, &=, difference_update, etc.). Tais operações não fazem sentido no mundo ideal dos conjuntos matemáticos, e também não são implementadas em frozenset.

A Operadores e métodos de comparação de conjuntos que devolvem um booleano lista predicados de conjuntos: operadores e métodos que devolvem True ou False.

Além de operadores e métodos derivados da teoria matemática dos conjuntos, os tipos conjunto implementam outros métodos para tornar seu uso prático, resumidos na Métodos adicionais de conjuntos.

Isso encerra nossa visão geral dos recursos dos conjuntos. Como prometido na Views de dicionários, vamos agora ver como dois dos tipos de views de dicionários se comportam de forma muito similar a um frozenset.