Os tópicos tratados aqui são muito estáveis e fundamentais. Não foi introduzida nenhuma mudança digna de nota nesta segunda edição.

Acrescentei um exemplo usando is para testar a existência de um objeto sentinela, e um aviso sobre o mau uso do operador is no final da Escolhendo Entre == e is.

Este capítulo estava na Parte IV, mas decidi abordar esses temas mais cedo, pois eles funcionam melhor como o encerramento da Parte II, “Estruturas de Dados”, que como abertura de “Práticas de Orientação a Objetos"

Vamos começar desaprendendo que uma variável é como uma caixa onde você guarda dados.

Em 1997, fiz um curso de verão sobre Java no MIT. A professora, Lynn Stein^[1] apontou que a metáfora comum, de “variáveis como caixas”, na verdade atrapalha o entendimento de variáveis de referência em linguagens orientadas a objetos. As variáveis em Python são como variáveis de referência em Java; uma metáfora melhor é pensar em uma variável como uma etiqueta que dá nome a um objeto. O exemplo e a figura a seguir ajudam a entender o motivo disso.

O As variáveis a e b referem-se à mesma lista, não a cópias da lista. é uma interação simples que não pode ser explicada por “variáveis como caixas”.

1. Cria uma lista [1, 2, 3] e a vincula à variável a.

2. Vincula a variável b ao mesmo valor referenciado por a.

3. Modifica a lista referenciada por a, anexando um novo item.

4. É possível ver o efeito através da variável b. Se você pensar em b como uma caixa que guardava uma cópia de [1, 2, 3] da caixa a, este comportamento não faz sentido.

A Se você imaginar variáveis como caixas, não é possível entender a atribuição em Python; por outro lado, imagine variáveis como etiquetas autocolantes e o [ex_a_b_refs] é facilmente explicável. explica por que a metáfora da caixa está errada em Python, enquanto etiquetas apresentam uma imagem mais útil para entender como variáveis funcionam.

Assim, a instrução b = a não copia o conteúdo de uma caixa a para uma caixa b. Ela cola uma nova etiqueta b no objeto que já tem a etiqueta a.

A professora Stein também falava sobre atribuição de uma maneira bastante específica. Por exemplo, quando discutia sobre um objeto representando uma gangorra em uma simulação, ela dizia: “A variável g foi atribuída à gangorra”, mas nunca “A gangorra foi atribuída à variável g”. Com variáveis de referência, faz mais sentido dizer que a variável é atribuída a um objeto, não o contrário. Afinal, o objeto é criado antes da atribuição. O Variáveis são vinculadas a objetos somente após os objetos serem criados prova que o lado direito de uma atribuição é processado primeiro.

Já que o verbo “atribuir” é usado de diferentes maneiras, “vincular” é uma alternativa melhor: a declaração de atribuição em Python x = … vincula o nome x ao objeto criado ou referenciado no lado direito. E o objeto precisa existir antes que um nome possa ser vinculado a ele, como demonstra o Variáveis são vinculadas a objetos somente após os objetos serem criados.

1. A saída Gizmo id: … é um efeito colateral da criação de uma instância de Gizmo.

2. Multiplicar uma instância de Gizmo levanta uma exceção.

3. Aqui está a prova de que um segundo Gizmo foi de fato instanciado antes que a multiplicação fosse tentada.

4. Mas a variável y nunca foi criada, porque a exceção aconteceu enquanto a parte direita da atribuição estava sendo executada.

Como variáveis são apenas meras etiquetas, nada impede que um objeto tenha várias etiquetas vinculadas a si. Quando isso acontece, você tem apelidos (aliases), nosso próximo tópico.

Lewis Carroll é o pseudônimo literário do Prof. Charles Lutwidge Dodgson. O Sr. Carroll não é apenas igual ao Prof. Dodgson, eles são exatamente a mesma pessoa. charles e lewis se referem ao mesmo objeto expressa essa ideia em Python.

1. lewis é um apelido para charles.

2. O operador is e a função id confirmam essa afirmação.

3. Adicionar um item a lewis é o mesmo que adicionar um item a charles.

Entretanto, suponha que um impostor—vamos chamá-lo de Dr. Alexander Pedachenko—diga que é o verdadeiro Charles L. Dodgson, nascido em 1832. Suas credenciais podem ser as mesmas, mas o Dr. Pedachenko não é o Prof. Dodgson. charles e lewis estão vinculados ao mesmo objeto; alex está vinculado a um objeto diferente de valor igual. ilustra esse cenário.

O alex e charles são iguais quando comparados, mas alex não é charles constrói e testa o objeto alex como apresentado em charles e lewis estão vinculados ao mesmo objeto; alex está vinculado a um objeto diferente de valor igual..

1. alex é uma referência a um objeto que é uma réplica do objeto vinculado a charles.

2. Os objetos são iguais quando comparados devido à implementação de __eq__ na classe dict.

3. Mas são objetos distintos. Essa é a forma pythônica de escrever a negação de uma comparação de identidade: a is not b.

charles e lewis se referem ao mesmo objeto é um exemplo de apelidamento (aliasing). Naquele código, lewis e charles são apelidos: duas variáveis vinculadas ao mesmo objeto. Por outro lado, alex não é um apelido para charles: essas variáveis estão vinculadas a objetos diferentes. Os objetos vinculados a alex e charles tem o mesmo valor  — é isso que == compara — mas têm identidades diferentes.

Na Referência da Linguagem Python, está escrito:

A identidade de um objeto nunca muda após ele ter sido criado; você pode pensar nela como o endereço do objeto na memória. O operador is compara a identidade de dois objetos; a função id() retorna um inteiro representando essa identidade.

O verdadeiro significado do id de um objeto depende da implementação da linguagem. Em CPython, id() retorna o endereço de memória do objeto, mas outro interpretador Python pode retornar algo diferente. O ponto fundamental é que o id será sempre um valor numérico único, e ele nunca mudará durante a vida do objeto.

Na prática, raramente usamos a função id() quando programamos. A verificação de identidade é feita, na maior parte das vezes, com o operador is, que compara os IDs dos objetos, então nosso código não precisa chamar id() explicitamente. A seguir falamos sobre is versus ==.

A forma mais fácil de copiar uma lista (ou a maioria das coleções mutáveis nativas) é usando o construtor padrão do próprio tipo. Por exemplo:

1. list(l1) cria uma cópia de l1.

2. As cópias são iguais…​

3. …​mas se referem a dois objetos diferentes.

Para listas e outras sequências mutáveis, o atalho l2 = l1[:] também cria uma cópia.

Contudo, tanto o construtor quanto [:] produzem uma cópia rasa (shallow copy). Isto é, o contêiner externo é duplicado, mas a cópia é preenchida com referências para os mesmos itens contidos no contêiner original. Isso economiza memória e não causa qualquer problema se todos os itens forem imutáveis. Mas se existirem itens mutáveis, isso pode gerar surpresas desagradáveis.

No Criando uma cópia rasa de uma lista contendo outra lista; copie e cole esse código para vê-lo animado no Online Python Tutor criamos uma lista contendo outra lista e uma tupla, e então fazemos algumas mudanças para ver como isso afeta os objetos referenciados.

1. l2 é uma cópia rasa de l1. Este estado está representado em Estado do programa imediatamente após a atribuição l2 = list(l1) em [ex_shallow_copy]. l1 e l2 se referem a listas diferentes, mas as listas compartilham referências para os mesmos objetos internos, a lista [66, 55, 44] e para a tupla (7, 8, 9). (Diagrama gerado pelo Online Python Tutor).

2. Concatenar 100 a l1 não tem qualquer efeito sobre l2.

3. Aqui removemos 55 da lista interna l1[1]. Isso afeta l2, pois l2[1] está associado à mesma lista em l1[1].

4. Para um objeto mutável como a lista referida por l2[1], o operador += altera a lista diretamente. Essa mudança é visível em l1[1], que é um apelido para l2[1].

5. += em uma tupla cria uma nova tupla e reassocia a variável l2[2] a ela. Isso é equivalente a fazer l2[2] = l2[2] + (10, 11). Agora as tuplas na última posição de l1 e l2 não são mais o mesmo objeto. Veja a Estado final de l1 e l2: elas ainda compartilham referências para o mesmo objeto lista, que agora contém [66, 44, 33, 22], mas a operação l2[2] += (10, 11) criou uma nova tupla com conteúdo (7, 8, 9, 10, 11), sem relação com a tupla (7, 8, 9) referenciada por l1[2]. (Diagram generated by the Online Python Tutor.).

A saída de Criando uma cópia rasa de uma lista contendo outra lista; copie e cole esse código para vê-lo animado no Online Python Tutor é Saída de [ex_shallow_copy], e o estado final dos objetos está representado em Estado final de l1 e l2: elas ainda compartilham referências para o mesmo objeto lista, que agora contém [66, 44, 33, 22], mas a operação l2[2] += (10, 11) criou uma nova tupla com conteúdo (7, 8, 9, 10, 11), sem relação com a tupla (7, 8, 9) referenciada por l1[2]. (Diagram generated by the Online Python Tutor.).

Já deve estar claro que cópias rasas são fáceis de criar, mas podem ou não ser o que você quer. Nosso próximo tópico é a criação de cópias profundas.

O único modo de passagem de parâmetros em Python é a chamada por compartilhamento (call by sharing). É o mesmo modo usado na maioria das linguagens orientadas a objetos, incluindo JavaScript, Ruby e Java (em Java isso se aplica aos tipos de referência; tipos primitivos usam a chamada por valor). Chamada por compartilhamento significa que cada parâmetro formal da função recebe uma cópia de cada referência nos argumentos. Em outras palavras, os parâmetros dentro da função se tornam apelidos dos argumentos passados.

O resultado desse esquema é que a função pode modificar qualquer objeto mutável passado a ela como parâmetro, mas não pode mudar a identidade daqueles objetos (isto é, ela não pode substituir integralmente um objeto por outro). O Uma função pode mudar qualquer objeto mutável que receba mostra uma função simples usando += com um de seus parâmetros. Quando passamos números, listas e tuplas para a função, os argumentos originais são afetados de maneiras diferentes. Veja só:

1. O número x não se altera.

2. A lista a é alterada.

3. A tupla t não se altera.

Outra questão relacionada a parâmetros de função é o uso de valores mutáveis como defaults, discutida a seguir.

Os objetos nunca são destruídos explicitamente; no entanto, quando eles se tornam inacessíveis, eles podem ser coletados como lixo.

A primeira surpresa de del é não ser uma função, mas uma instrução (statement).

Escrevemos del x e não del(x)—apesar dessa última forma funcionar também, mas apenas porque as expressões x e (x) em geral tem o mesmo significado em Python.

O segundo aspecto surpreendente é que del apaga referências, não objetos. A coleta de lixo pode eliminar um objeto da memória como resultado indireto de del, se a variável apagada for a última referência ao objeto. Reassociar uma variável também pode reduzir a zero o número de referências a um objeto, causando sua destruição.

1. Cria o objeto [1, 2] e vincula a a ele.

2. Vincula b ao mesmo objeto [1, 2].

3. Apaga a referência a.

4. [1, 2] não é afetado, pois b ainda aponta para ele.

5. Reassociar b a um objeto diferente remove a última referência restante a [1, 2]. Agora o coletor de lixo pode descartar aquele objeto.

No CPython, o algoritmo primário de coleta de lixo é a contagem de referências. Essencialmente, cada objeto mantém uma contagem do número de referências apontando para si. Assim que a contagem chega a zero, o objeto é imediatamente destruído: CPython invoca o método __del__ no objeto (se definido) e daí libera a memória alocada para aquele objeto. No CPython 2.0, um algoritmo de coleta de lixo geracional foi acrescentado, para detectar grupos de objetos envolvidos em referências cíclicas—grupos que podem ser inacessíveis mesmo que existam referências restantes, quando todas as referências mútuas estão contidas dentro daquele grupo. Outras implementações de Python tem coletores de lixo mais sofisticados, que não se baseiam na contagem de referências, o que significa que o método __del__ pode não ser chamado imediatamente quando não existem mais referências ao objeto. Veja "PyPy, Garbage Collection, and a Deadlock" (EN) de A. Jesse Jiryu Davis para uma discussão sobre os usos próprios e impróprios de __del__.

Para demonstrar o fim da vida de um objeto, Detectando o fim de um objeto quando não resta nenhuma referência apontando para ele usa weakref.finalize para registrar uma função callback a ser chamada quando o objeto é destruído.

1. s1 e s2 são apelidos do mesmo conjunto, {1, 2, 3}.

2. Para essa demonstração, a função bye não deve ser um método vinculado ao objeto prestes a ser destruído, nem manter uma referência para o objeto.

3. Registra o callback bye no objeto referenciado por s1.

4. O atributo .alive é True antes do objeto finalize ser chamado.

5. Como vimos, del não apaga o objeto, apenas a referência s1 a ele.

6. Reassociar a última referência, s2, torna {1, 2, 3} inacessível. Ele é destruído, o callback bye é invocado, e ender.alive se torna False.

O ponto principal de Detectando o fim de um objeto quando não resta nenhuma referência apontando para ele é mostrar explicitamente que del não apaga objetos, mas que objetos podem ser apagados como uma consequência de ficarem inacessíveis após o uso de del.

Você pode estar se perguntando porque o objeto {1, 2, 3} foi destruído em Detectando o fim de um objeto quando não resta nenhuma referência apontando para ele. Afinal, a referência s1 foi passada para a função finalize, que precisa tê-la mantido para conseguir monitorar o objeto e invocar o callback. Isso funciona porque finalize mantém uma referência fraca (weak reference) para {1, 2, 3}. Referências fracas não aumentam a contagem de referências de um objeto. Assim, uma referência fraca não evita que o objeto alvo seja removido pelo coletor de lixo. Referências fracas são úteis em cenários de caching, pois não queremos que os objetos "cacheados" sejam mantidos vivos apenas por terem uma referência no cache.

Fiquei surpreso ao descobrir que, dada uma tupla t, a chamada t[:] não cria uma cópia, mas devolve uma referência para o mesmo objeto. Da mesma forma, tuple(t) também retorna uma referência para a mesma tupla.^[4]

Uma tupla construída a partir de outra é, na verdade, exatamente a mesma tupla. demonstra esse fato.

1. t1 e t2 estão vinculadas ao mesmo objeto

2. Assim como t3.

Podemos observar o mesmo comportamento com instâncias de str, bytes e frozenset. Note que frozenset não é uma sequência, então fs[:] não funciona se fs é um frozenset. Mas fs.copy() tem o mesmo efeito: ele trapaceia e retorna uma referência ao mesmo objeto, e não uma cópia.^[5]

O Strings e inteiros literais podem criar objetos compartilhados. mostra outra otimização, relacionada aos tipos str e int:

1. Criando duas str com o mesmo valor.

2. Surpresa: a e b se referem ao mesmo objeto str!

3. Alguns inteiros pequenos são compartilhados.

4. Outros inteiros não são compartilhados.

O compartilhamento de strings literais é uma técnica de otimização chamada internalização (interning). O CPython usa uma técnica similar com inteiros pequenos, para evitar a duplicação desnecessária de números que aparecem com muita frequência em programas, como 0, 1, -1, 10, etc. Observe que o CPython não internaliza todas as strings e inteiros, e o critério pelo qual ele faz isso é um detalhe de implementação não documentado.

Os truques discutidos nessa seção, incluindo o comportamento de frozenset.copy(), são mentiras inofensivas que economizam memória e tornam o interpretador mais rápido. Não se preocupe, elas não trarão nenhum problema, pois se aplicam apenas a tipos imutáveis. Provavelmente, o melhor uso para esse tipo de detalhe é ganhar apostas contra outros Pythonistas.^[6]

Todo objeto em Python tem uma identidade, um tipo e um valor. Apenas o valor do objeto pode mudar ao longo do tempo.^[7]

Se duas variáveis se referem a objetos imutáveis de valor igual (quando a == b é True), na prática, dificilmente importa se elas se referem a cópias de mesmo valor ou são apelidos do mesmo objeto, porque o valor de objeto imutável não muda, com uma exceção. A exceção são as tuplas: se ela contém referências para itens mutáveis, então seu valor mudará se o valor de um item mutável for alterado. Na prática, esse cenário não é tão comum. O que nunca muda numa coleção imutável são as identidades dos objetos mantidos ali. A classe frozenset não sofre desse problema, porque ela só pode conter elementos hashable, e o valor de um objeto hashable não pode mudar, por definição.

O fato de variáveis conterem referências tem muitas consequências práticas para a programação em Python:

• Uma atribuição simples não cria cópias.

• Uma atribuição composta com += ou *= cria novos objetos se a variável à esquerda da atribuição estiver vinculada a um objeto imutável, mas pode modificar um objeto mutável diretamente.

• Atribuir um novo valor a uma variável existente não muda o objeto previamente vinculado à variável. Isso se chama rebinding (re-vinculação); a variável passa a se referir a um objeto diferente. Se aquela variável era a última referência ao objeto anterior, aquele objeto será eliminado pela coleta de lixo.

• Parâmetros de função são passados como apelidos, o que significa que a função pode alterar qualquer objeto mutável recebido como argumento. Não há como evitar isso, exceto criando cópias locais ou usando objetos imutáveis (i.e., passando uma tupla em vez de uma lista)

• Usar objetos mutáveis como valores default de parâmetros de função é perigoso, pois se os parâmetros forem modificados pela função, o default muda, afetando chamadas posteriores que usem o default.

Em CPython, um objeto é descartado assim que o número de referências a ele chega a zero. Objetos também podem ser descartados se formarem grupos com referências cíclicas sem nenhuma referência externa ao grupo.

Em algumas situações, pode ser útil manter uma referência para um objeto que não vai, por si só, manter o objeto vivo. Um exemplo é uma classe que queira manter o registro de todas as suas instâncias atuais. Isso pode ser feito com referências fracas, um mecanismo de baixo nível encontrado nas coleções WeakValueDictionary, WeakKeyDictionary, WeakSet, e na função finalize do módulo weakref.

Leia "Weak References" em https://fluentpython.com para mais detalhes sobre weakref.

O capítulo "Modelo de Dados" de A Referência da Linguagem Python inicia com uma explicação bastante clara sobre identidades e valores de objetos.

Wesley Chun, autor da série Core Python, apresentou Understanding Python’s Memory Model, Mutability, and Methods (EN) na EuroPython 2011, discutindo não apenas o tema desse capítulo como também o uso de métodos especiais.

Doug Hellmann escreveu os posts "copy — Duplicate Objects" (EN) e "weakref — Garbage-Collectable References to Objects" (EN), cobrindo alguns dos tópicos que acabamos de tratar.

Você pode encontrar mais informações sobre o coletor de lixo geracional do CPython em gc — Interface para o coletor de lixo, que começa com a frase "Este módulo fornece uma interface para o coletor de lixo opcional." O adjetivo "opcional" aqui pode ser surpreendente, mas o capítulo "Modelo de Dados" também afirma:

Uma implementação tem permissão para adiar a coleta de lixo ou omiti-la completamente — é um detalhe de implementação como a coleta de lixo é implementada, desde que nenhum objeto que ainda esteja acessível seja coletado.

Pablo Galindo escreveu um texto mais aprofundado sobre o Coletor de Lixo em Python, em "Design of CPython’s Garbage Collector" (EN) no Python Developer’s Guide, voltado para contribuidores novos e experientes da implementação CPython.

O coletor de lixo do CPython 3.4 aperfeiçoou o tratamento de objetos contendo um método __del__, como descrito em PEP 442—​Safe object finalization (EN).

A Wikipedia tem um artigo sobre string interning (EN), que menciona o uso desta técnica em várias linguagens, incluindo Python.

A Wikipedia também tem um artigo sobre "Haddocks' Eyes", a canção de Lewis Carroll que mencionei no início deste capítulo. Os editores da Wikipedia escreveram que a letra é usada em trabalhos de lógica e filosofia "para elaborar o status simbólico do conceito de 'nome': um nome como um marcador de identificação pode ser atribuído a qualquer coisa, incluindo outro nome, introduzindo assim níveis diferentes de simbolização."