UnificandoTiposClasses

por Guido van Rossum <guido@python.org>

Índice

Conteúdo

  1. Índice
  2. Introdução
  3. Subclasses de "built-ins"
  4. Built-ins como "factory-functions"
  5. Instrospecção de instâncias de built-ins
  6. Métodos estáticos e métodos de classe
  7. Propriedades: atributos gerenciados por métodos get/set
  8. Ordem de Resolução de Métodos
    1. Discordâncias de ordem
  9. Métodos cooperativos e "super"
    1. Exemplo: escrevendo super() em Python
  10. Redefinindo o método __new__
  11. Metaclasses
    1. Exemplos de Metaclasses
  12. Incompatibilidades
  13. Referências

Introdução

Em sua versão 2.2, Python introduz a primeira fase da "unificação de tipos/classes", uma série de mudanças na linguagem, com o intuito de remover a maior parte das diferenças entre tipos "built-in" e classes definidas pelo usuário. Talvez a mais óbvia seja a restrição contra o uso de built-ins (list e dict, por exemplo) como classes base em uma definição de classe. O artigo "Python Warts" (http://www.amk.ca/python/writing/warts.htm) de Andrew Kuchling dedica uma das suas mais longas seções a essa deficiência da linguagem. Por um acaso, o outro artigo de Andrew, What's New in Python 2.2 (http://www.amk.ca/python/2.2/), também traz uma boa descrição de outras novidades na versão 2.2.

Esta é uma das maiores mudanças já feitas à Python, e ainda assim pode ser feita gerando pouquíssimas incompatibilidades com código já existente. As mudanças são descritas em detalhes em uma série de PEPs (Python Enhancement Proposals), mas elas não são tutoriais e em particular as que descrevem a unificação de tipos e classes são de díficil compreensão, além de ainda não estarem finalizadas. Esta é finalidade deste artigo: ele introduz os elementos chave da unificação para o programador comum.

Alguns termos usados: "Python clássica" refere-se à versão 2.1 (e seus patches, como 2.1.1) ou versões anteriores, enquanto "classes tradicionais" refere-se à classes definidas sem derivar de um built-in, seja porque não deriva de classe alguma ou porque todas suas classes base também são classes tradicionais, aplicando a definição recursivamente.

Classes tradicionais ainda são uma categoria especial em Python 2.2. Com o tempo, elas serão totalmente unificadas com tipos, mas devido à incompatibilidades adicionais, isso ocorrerá depois da versão 2.2 (talvez não antes da versão 3.0). Eu tentarei usar "tipo" quando me referir a um tipo built-in e "classe" quando me referir a uma classe tradicional ou algo que pode ser qualquer um dos dois; em casos que não ficar claro pelo contexto, eu serei explícito usando "classes tradicionais" ou "classe" ou "tipo".

Subclasses de "built-ins"

Vamos começar com a melhor parte: você agora pode criar subclasses de built-ins, como dict e list. Tudo que você precisa é uma classe base que seja um tipo built-in e pronto.

Agora que tipos têm um papel mais central, é apropriado ter nomes para os tipos que provavelmente serão usados, o nome dict para dicionários por exemplo. Mas há ainda duas outras maneiras de nomear esse tipo: type({}) e (depois de importar o módulo types) types.DictType (ou types.DictionaryType).

Segue um exemplo de uma subclasse de dict, que contém um "valor padrão", retornado quando uma chave inexistente é requisitada: 

   1 class defaultdict(dict):
   2 
   3     def __init__(self, default=None):
   4         dict.__init__(self)
   5         self.default = default
   6 
   7     def __getitem__(self, key):
   8         try:
   9             return dict.__getitem__(self, key)
  10         except KeyError:
  11             return self.default

Este exemplo demonstra algumas coisas. O método __init__() extende o método dict.__init__(), e tem uma lista diferente de argumentos. De forma semelhante, o método __getitem__() extende o método dict.__getitem__().

O método __getitem__() poderia também ser escrito da seguinte forma, usando a nova condição "key in dict" introduzida na versão 2.2: 

   1     def __getitem__(self, key):
   2         if key in self:
   3             return dict.__getitem__(self, key)
   4         else:
   5             return self.default

Eu creio que esta forma é menos eficiente, porque ela verifica a chave duas vezes. A exceção seria quando nós esperamos que a chave quase nunca esteja no dicionário: então, falhar o try/except é muito mais dispendioso do que falhar o teste "key in self".

O método get() provavelmente também deve ser extendido, para usar o mesmo padrão que __getitem__(): 

   1     def get(self, key, *args):
   2         if not args:
   3             args = (self.default,)
   4         return dict.get(self, key, *args)

Apesar dessa função ser declarada com uma lista de argumentos de comprimento variável, ela deve ser chamada com apenas um ou dois argumentos. Se mais forem passados, a chamada do método da classe base irá levantar uma exceção TypeError.

Nós não estamos restritos a extender métodos definidos na classe base. Aqui está um método útil que faz algo similar a update(), mas mantém os valores existentes ao invés de sobrescrevê-los com novos valores se uma chave existe em ambos os dicionários. 

   1     def merge(self, other):
   2         for key in other:
   3             if key not in self:
   4                 self[key] = other[key]

Esse método utiliza a nova condição "key not in dict", assim como "for key in dict" para iterar eficientemente (sem ter de fazer uma cópia da lista de chaves) por todas as chaves do dicionário. Ele não requer que o argumento "other" seja outro defaultdict, ou nem mesmo um outro dicionário: qualquer objeto que suporte "for key in other" e other[key] irá funcionar.

Aqui está o novo tipo funcionando: 

>>> print defaultdict               # mostra nosso tipo
<class '__main__.defaultdict'>
>>> print type(defaultdict)         # sua metaclasse
<type 'type'>
>>> a = defaultdict(default=0.0)    # cria uma instância
>>> print a                         # mostra a instância
{}
>>> print type(a)                   # mostra seu tipo
<class '__main__.defaultdict'>
>>> print a.__class__               # mostra sua classe
<class '__main__.defaultdict'>
>>> print type(a) is a.__class__    # seu tipo é sua classe
1
>>> a[1] = 3.25                     # modifica a instância
>>> print a                         # mostra o novo valor
{1: 3.25}
>>> print a[1]                      # mostra o novo item
3.25
>>> print a[0]                      # um item não existente
0.0
>>> a.merge({1:100, 2:200})         # usa um método
>>> print a                         # mostra o resultado
{1: 3.25, 2: 200}
>>>

Nós podemos ainda usar o novo tipo em contextos onde tradicionalmente apenas dicionários "reais" seriam permitidos, como nos argumentos para locais/globais em um comando exec ou na função eval(): 

>>> print a.keys()
[1, 2]
>>> exec "x = 3; print x" in a
3
>>> print a.keys()
['__builtins__', 1, 2, 'x']
>>> print a['x']
3
>>>

No entanto, nosso método __getitem__() não é usado no acesso às variáveis pelo interpretador: 

>>> exec "print foo" in a
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in ?
NameError: name 'foo' is not defined
>>>

Por que não foi mostrado 0.0? O interpretador usa uma função interna para acessar o dicionário, que passa por cima do nosso método __getitem__(). Eu admito que isso pode ser um problema, (apesar de ser um problema apenas nesse contexto, quando uma derivada de dict é usada como dicionário de locais/globais); ainda está em aberto se isso poderá ser corrigido sem comprometer a performance nos casos mais comuns.

Agora nós vamos ver se instâncias de defaultdict têm váriáveis dinâmicas, assim como classes tradicionais: 

>>> a.default = -1
>>> print a["noway"]
-1
>>> a.default = -1000
>>> print a["noway"]
-1000
>>> print a.__dict__.keys()
['default']
>>> a.x1 = 100
>>> a.x2 = 200
>>> print a.x1
100
>>> print a.__dict__.keys()
['default', 'x2', 'x1']
>>> print a.__dict__
{'default': -1000, 'x2': 200, 'x1': 100}
>>>

Isso pode nem sempre ser o que você quer; além disso, usar um dicionário separado para conter uma única variável dobra a memória usada por uma instância de defaultdict comparada com um dict normal! Há uma forma de evitar isso: 

   1 class defaultdict2(dict):
   2 
   3     __slots__ = ['default']
   4 
   5     def __init__(self, default=None):
   6     ''...(like before)...''

A declaração __slots__ pega uma lista de variáveis e reserva espaço na instância para elas. Quando __slots__ é usada, outras variáveis não podem ser definidas: 

>>> a = defaultdict2(default=0.0)
>>> a[1]
0.0
>>> a.default = -1
>>> a[1]
-1
>>> a.x1 = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'defaultdict2' object has no attribute 'x1'
>>>

Alguns avisos e detalhes sobre __slots__:

Note que enquanto na maioria dos casos a sobrecarga de operadores funciona da mesma forma que para classes tradicionais, há algumas diferenças. (a maior delas é a ausência de suporte a __coerce__; classes novas devem sempre usar a nova API numérica, que passa os operandos diretamente para __add__, __radd__, etc.)

Há uma nova forma de redefinir acesso a atributos. O gancho __getattr__, se definido, funciona exatamente como para classes tradicionais: só é chamado se as formas regulares de encontrar um atributo não funcionarem. Mas você pode agora redefinir __getattribute__, uma nova operação que é chamada para todas as buscas de atributos.

Quando redefinir __getattribute__, tenha em mente que é fácil causar recursão infinita: sempre que __getattribute__ referenciar um atributo de self, (mesmo self.__dict__), ele é chamado recursivamente. (Similar a __setattr__, que é chamada para todas as definições de atributos; __getattr__ pode também sofrer disso quando é escrita sem cuidado e referencia um atributo inexistente de self.)

A forma correta de acessar qualquer atributo de self em __getattribute__ é chamar o __getattribute__ da classe base, da mesma forma que qualquer método que sobrescreva um método de uma classe base pode chamar o método original: Base.__getattribute__(self, nome). (veja tambéma discussão sobre super() logo abaixo se você quer ser o mais correto possível quando usar herança múltipla.)

Aqui segue um exemplo de redefinição de __getattribute__ (na verdade, extendendo ele, uma vez que o método redefinido chama o método da classe base). 

   1 class C(object):
   2     def __getattribute__(self, name):
   3         print "accessing %r.%s" % (self, name)
   4         return object.__getattribute__(self, name)

Uma nota sobre __setattr__: algumas vezes atributos não são armazenados em self.__dict__ (por exemplo, usando __slots__ ou propriedades, ou quando usando um tipo built_in como classe base). Se aplica o mesmo padrão usado em __getattribute__, onde você pode chamar o método __setattr__ da classe base para fazer o trabalho. Um exemplo: 

   1 class C(object):
   2     def __setattr__(self, name, value):
   3         if hasattr(self, name):
   4             raise AttributeError, "attributes are write-once"
   5         object.__setattr__(self, name, value)

Programadores de C++ podem achar útil que está forma de subtipos em Python é implementada de forma bem semelhante à herança-simples em C++, com __class__ no papel de vtable.

Há muito mais que pode ser explicado (como a declaração __metaclass__ e o método __new__), mas a maior parte é bem esotérica. Veja sobre "__new__" logo abaixo se você estiver interessado.

Vou terminar com uma lista de avisos:

Built-ins como "factory-functions"

A seção anterior mostrou como uma instância do subtipo defaultdict pode ser criada chamando defaultdict(). Isso é esperado, porque também funciona para classes tradicionais. Mas aqui há uma nova função: built-ins podem gerar instâncias chamando o tipo diretamente.

Para vários tipos built-in já haviam funções geradoras com o nome do tipo, str() e int() por exemplo. Eu alterei estes nomes de forma que agora eles nomeiam os tipos correspondentes. Apesar disso alterar esses objetos, de funções para tipos, eu não imagino que irá criar qualquer problema de compatibilidade: me assegurei de que os tipos podem ser chamados com exatamente as mesmas listas de argumentos que as funções antigas. (Também podem ser chamadas sem argumentos, produzindo um objeto com um valor padrão como zero, ou vazio.)

Estes são os built-ins afetados:

A assinatura de type() requer uma explicação: tradicionalmente, type(x) retornava o tipo do objeto x, e esta forma ainda funciona. No entanto, type(nome, bases, métodos) é uma nova forma que cria um novo tipo.

Existem ainda outros built-ins que seguem o mesmo padrão. Estes serão descritos abaixo.

Esta mudança tem dois propósitos. Primeiro, torna conveniente o use desses tipos como classes base em uma definição de classe. Segundo, torna mais fácil testar o tipo de um objeto: ao invés de escrever type(x) is type(0), você pode agora escrever isinstance(x, int).

O que me lembra que o segundo argumento de isinstance() pode ser também um tuple de classes ou tipos. Por exemplo, isinstance(x, (int, long)) retorna True quando x for um int ou um long (ou uma instância de uma subclasse de um desses tipos), e similarmente, isinstance(x, (str, unicode)) testa para uma string de um dos dois tipos. O mesmo não ocorre com isclass().

Instrospecção de instâncias de built-ins

Para instâncias de tipos, x.__class__ é o mesmo que type(x): 

>>> type([])
<type 'list'>
>>> [].__class__
<type 'list'>
>>> list
<type 'list'>
>>> isinstance([], list)
1
>>> isinstance([], dict)
0
>>> isinstance([], object)
1
>>>

Em Python 2.1, os nomes de métodos de objetos estava disponíveis como o atributo __methods__, tendo o mesmo efeito da função dir(): 

Python 2.1 (#30, Apr 18 2001, 00:47:18)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> [].__methods__
['append', 'count', 'extend', 'index', 'insert', 'pop',
'remove', 'reverse', 'sort']
>>>
>>> dir([])
['append', 'count', 'extend', 'index', 'insert', 'pop',
'remove', 'reverse', 'sort']

Na nova proposta, o atributo __methods__ não existe mais: 

Python 2.2c1 (#803, Dec 13 2001, 23:06:05)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> [].__methods__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'list' object has no attribute '__methods__'
>>>

Ao invés disso, você pode usar a função dir(), que agora provê muito mais informação: 

>>> dir([])
['__add__', '__class__', '__contains__', '__delattr__',
'__delitem__', '__eq__', '__ge__', '__getattribute__',
'__getitem__', '__getslice__', '__gt__', '__hash__', '__iadd__',
'__imul__', '__init__', '__le__', '__len__', '__lt__', '__mul__',
'__ne__', '__new__', '__reduce__', '__repr__', '__rmul__',
'__setattr__', '__setitem__', '__setslice__', '__str__', 'append',
'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse',
'sort']
>>>

A nova dir() retorna mais informação que a antiga: além dos nomes de variáveis e métodos normais, ela também mostra os métodos que são normalmente chamados através de operadores como __iadd__ (+=), __len__ (len), __ne__ (!=), etc.

Mais sobre a função dir():

Você pode usar um método de um built-in como "unbound method": 

>>> a = ['tic', 'tac']
>>> list.__len__(a)          # mesmo que len(a)
2
>>> list.append(a, 'toe')    # mesmo que a.append('toe')
>>> a
['tic', 'tac', 'toe']
>>>

Isto é exatamente o mesmo que usar um método de uma classe e similarmente, é mais útil dentro de um método de uma subclasse, para chamar o método correspondente na classe base.

Diferentemente de classes definidas pelo usuário, você não pode alterar tipos built-in e o seu __dict__ é um objeto somente leitura. A restrição na definição de atributos é liberada para classes novas definidas pelo usuário, incluindo sobclasses de tipos built-ins; no entanto, mesmo estes têm um __dict__ somente leitura. Exemplo: 

>>> list.append
<method 'append' of 'list' objects>
>>> list.append = list.append
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't set attributes of built-in/extension type 'list'
>>> list.answer = 42
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't set attributes of built-in/extension type 'list'
>>> list.__dict__['append']
<method 'append' of 'list' objects>
>>> list.__dict__['answer'] = 42
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: object does not support item assignment
>>> class L(list):
...     pass
...
>>> L.append = list.append
>>> L.answer = 42
>>> L.__dict__['answer']
42
>>> L.__dict__['answer'] = 42
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: object does not support item assignment
>>>

Para os curiosos: há duas razões de porque alterar classes built-in não é permitido. Primeiro, seria muito fácil quebrar uma constante de um tipo que é usada em outro lugar, seja pela biblioteca padrão ou pelo código rodando. Segundo, quando Python é embutida em outra aplicação que cria múltiplos interpretadores, estes built-ins (sendo estruturas de dado alocadas estaticamente) são compartilhadas entre todos os interpretadores; então, código rodando em um interpretador pode quebrar o que esteja rodando em outro o que é inaceitável.

Métodos estáticos e métodos de classe

A nova API torna possível adicionar métodos estáticos e métodos de classe. Métodos estáticos são fáceis de descrever: eles se comportam de maneira bem semelhante a métodos estáticos em C++ ou Java. Um exemplo: 

   1 class C:
   2     def foo(x, y):
   3         print "staticmethod", x, y
   4     foo = staticmethod(foo)
   5 
   6 C.foo(1, 2)
   7 c = C()
   8 c.foo(1, 2)

Ambas as chamadas C.foo(1, 2) e c.foo(1, 2) chamam foo() com os dois argumentos e mostram "staticmethod 1 2". Não há nenhuma declaração de "self" na definição de foo() e nenhuma instância é requerida para a execução. Se o método for chamado em uma instância, ela é usada apenas para encontrar a classe que define o método estático. Isso funciona para ambos os tipos de classes, tradicionais ou novas.

A linha "foo = staticmethod(foo)" na definição da classe é o elemento crucial: ela torna foo() um método estático. O built-in staticmethod() envolve a função recebida como argumento em um tipo especial de descritor cujo __get__() retorna a função original inalterada.

Mais sobre __get__: em Python 2.2, a mágica de ligar métodos a instâncias (mesmo para classes tradicionais!) é feita através do método __get__ do objeto encontrado na classe. O método __get__ para funções regulares retorna um método ligado; __get__ para objetos do tipo staticmethod retorna a funcão usada. Se um atributo da classe não tiver um método __get__, ele jamais é ligado a uma instância, ou em outras palavras, há uma operação __get__ padrão que retorna o objeto inalterado; é assim que variáveis simples em uma classe são manipuladas (valores numéricos, por exemplo).

Métodos de classe usam um padrão similar para declarar métodos que recebem um primeiro argumento implícito que é a classe para a qual eles são chamados. Não há nenhum equivalente em C++ ou Java para isso, e não é exatamente igual aos métodos de classe em Smalltalk, mas servem um propósito similar. (Python também tem metaclasses reais, e talvez métodos definidos em uma metaclasse tenham mais direito ao nome "método da classe", mas eu imagino que a maior parte dos programadores não irá utilizar metaclasses.) Segue um exemplo: 

   1 class C:
   2     def foo(cls, y):
   3         print "classmethod", cls, y
   4     foo = classmethod(foo)
   5 
   6 C.foo(1)
   7 c = C()
   8 c.foo(1)

Ambas as chamadas C.foo(1) e c.foo(1) acabam chamando foo() com dois argumentos, e mostram "classmethod __main__.C 1". O primeiro argumento de foo() é implícito e é a classe, mesmo que o método tenha sido chamado através de uma instância. Agora vamos continuar com o exemplo: 

   1 class D(C):
   2     pass
   3 
   4 D.foo(1)
   5 d = D()
   6 d.foo(1)

Isso mostra "classmethod __main__.D 1" nas duas vezes; em outras palavras, a classe passada como primeiro argumento de foo() é a classe envolvida na chamada, mas não a classe envolvida na definição de foo().

No entanto, note isto: 

   1 class E(C):
   2     def foo(cls, y): # redefine C.foo
   3         print "E.foo() called"
   4         C.foo(y)
   5     foo = classmethod(foo)
   6 
   7 E.foo(1)
   8 e = E()
   9 e.foo(1)

Nesse exemplo, a chamada para C.foo() de E.foo() irá encontrar a classe C como seu primeiro argumento, não a classe E. Isso é o esperado, uma vez que a chamada especifica a classe C. Mas reforça a diferença entre estes métodos de classe e métodos definidos em metaclasses, onde uma chamada para um meta-método passaria explicitamente a classe alvo como primeiro argumento. (Se por acaso não entender isso, não se preocupe. Você não está sozinho.

Propriedades: atributos gerenciados por métodos get/set

Propriedades são uma forma interessante de implementar atributos cujo uso lembra chamadas de métodos. Eles são as vezes chamados de "atributos gerenciados". Em versões anteriores, você poderia fazer isso apenas sobrescrevendo __getattr__ e __setattr__; mas sobrescrever __setattr__ reduz consideravelmente a performance de qualquer definição de atributo, e é sempre um pouco complicado sobrescrever __getattr__ corretamente. Propriedades permitem que você faça isso impunemente, sem ter de sobrescrever __getattr__ ou __setattr__.

Primeiro mostrarei um exemplo. Vamos definir uma classe com um atributo x definido por dois métodos, getx() e setx(): 

   1 class C(object):
   2 
   3     def __init__(self):
   4         self.__x = 0
   5 
   6     def getx(self):
   7         return self.__x
   8 
   9     def setx(self, x):
  10         if x &lt; 0:
  11            x = 0
  12         self.__x = x
  13 
  14     x = property(getx, setx)

Uma pequena demonstração: 

    >>> a = C()
    >>> a.x = 10
    >>> print a.x
    10
    >>> a.x = -10
    >>> print a.x
    0
    >>> a.setx(12)
    >>> print a.getx()
    12
    >>>

A assinatura completa é property(fget=None, fset=None, fdel=None, doc=None). Os argumentos fget, fset e fdel são os métodos chamados quando o atributo é chamado, redefinido ou deletado. Se quaisquer destes três não for especificado (ou forem None), a operação correspondente irá levantar a exceção AttributeError. O quarto argumento é uma docstring para o atributo; ela pode ser usada através da classe como o exemplo seguinte demonstra: 

    >>> class C(object):
    ...     def getx(self): return 42
    ...     x = property(getx, doc="hello")
    ...
    >>> C.x.__doc__
    'hello'
    >>>

Detalhes sobre property() (todos são bastante avançados, exceto o primeiro):

Ordem de Resolução de Métodos

Quando herança múltipla entra em jogo, surge a questão da ordem de resolução dos métodos: a ordem em que uma método é procurado em uma classe e suas bases.

Em Python tradicional, a regra é dada pela seguinte função recursiva: 

   1 def classic_lookup(cls, name):
   2     "Verifica o nome em cls e classes base."
   3     if cls.__dict__.has_key(name):
   4         return cls.__dict__[name]
   5     for base in cls.__bases__:
   6         try:
   7             return classic_lookup(base, name)
   8         except AttributeError:
   9             pass
  10     raise AttributeError, name

Eu Python 2.2, decidi adotar uma regra diferente para classes novas (a regra para classes tradicionais continua inalterada por questão de compatibilidade; com o tempo, classes tradicionais desaparecerão e a distinção desaparecerão.) Tentarei explicar primeiro o que há de errado com a regra clássica:

O problema fica aparente quando usamos uma hierarquia em "diamante": 

              class A:
                ^ ^  def save(self): ...
               /   \
              /     \
             /       \
            /         \
        class B     class C:
            ^         ^  def save(self): ...
             \       /
              \     /
               \   /
                \ /
              class D

As setas apontam de um subtipo para seu tipo base. Este diagrama em particular mostra B e C derivando de A e D derivando de B e C (e indiretamente de A).

Diagmos que C redefine o método save(), que é definido na classe base A. (C.save() provavelmente chama A.save() e salva parte de seu próprio estado.) B e D não redefinem save(). Quando nós chamamos save() em uma instância de D, qual método é chamado? De acordo com a regra clássica, A.save() é chamado, ignorando C.save()!

Isso não é bom. Provavelmente quebrando C (seu estado não é salvo), rebatendo todo o propósito da hierarquia.

Por que isso não era um problema com classes tradicionais? Diagramas desde tipo são raramente encontrado em hierarquias de classe em Python. A maior parte das hierarquias usam herança simples, e herança múltipla é normalmente limitada a classes mix-in. De fato, o problema demonstrado aqui é a razão porque herança múltipla não é muito popular em Python!

Qual seria o problema com o novo sistema? O tipo 'object' no topo da hierarquia define uma série de métodos que podem ser extendidos por subtipos, por exemplo, __getattribute__() e __setattr__().

(Importante: o método __getattr__() não é a implementação real para a operação de pegar um atributo; ele só é usado quano um atributo não pode ser encontrado por meios normais. Isso é frequentemente citado como um problema - algumas classes realmente têm uma necessidade legítima de um método que seja chamado para todas as referências a atributos, e este problema é agora resolvido tornando __getattribute__() disponível. Mas este método tem de estar apto a chamar a implementação padrão de alguma forma. A forma mais natural é tornar a implementação padrão disponível como object.__getattribute__(self, name).)

Logo, uma hierarquia de classes tradicionais como essa: 

        class B     class C:
            ^         ^  __setattr__()
             \       /
              \     /
               \   /
                \ /
              class D

se tornaria um esquema em diamante dentro do novo sistema: 

              object:
                ^ ^  __setattr__()
               /   \
              /     \
             /       \
            /         \
        class B     class C:
            ^         ^  __setattr__()
             \       /
              \     /
               \   /
                \ /
              class D

E enquanto no original C.__setattr__() seria chamado, no novo sistema, object.__setattr__() seria chamado!

Felizmente, há uma regra de procura melhor. É um pouco complicado de explicar, mas ela faz a coisa certa na hierarquia de diamante, e é o mesmo que a regra clássica quando não há diamantes no gráfico da hierarquia (quando é uma árvore).

A nova regra constrói uma lista de todas as classes na ordem em que serão procuradas. Esta lista é feita quando a classe é definida, para economizar tempo. Para explicar a nova regra, vamos primeiro considerar como essa lista seria para a regra clássica. Note que na presença de diamantes, a regra clássica passa por algumas classes várias vezes. Por exemplo, no diagrama ABCD acima, a regra clássica passaria pelas classes nesta ordem: 

D, B, A, C, A

Note como que A aparece duas vezes na lista. A segunda ocorrência é redundante, uma vez que qualquer coisa que poderia ser encontrada já teria sido encontrada na primeira ocorrência. Mas ela é repassada mesmo assim (a implementação original não registra por quais classes já passou).

Nós usamos esta observação para explicar a nova regra. Usando a regra clássica, construímos a lista de onde procuraríamos, sem se preocupar com duplicatas. Depois, para cada classe que aparece mais de uma vez na lista, removemos todas as ocorrências, exceto a última. A lista resultante contain cada classe base apenas uma vez: D, B, C, A

Procurar por métodos nesta forma funciona com esquemas em diamante. Por causa da forma que a lista é construída, ela nunca altera a ordem em outras situações.

Isso é compatível com versões anteriores ? Não irá invalidar código existente ? Iria, se nós tivessemos alterado a ordem de resolução de métodos para topdas as classes, mas em Python 2.2 a nova regra só será aplicada a tipos, classes tradicionais continuam funcionando com a regra clássica.

Discordâncias de ordem

Esta seção é somente para leitores mais avançados. A implementação atual usa um algoritmo ligeiramente diferente, que pode retornar uma ordem diferente em alguns casos raros. A diferença apenas surge quando duas classes base aparecem em uma ordem diferente na lista de classes base para duas classes derivadas distintas, e essas duas classes são por suas vez classes base de uma outra. Aqui segue o menor exemplo capaz de demonstrar isso: 

   1 class A(object):
   2     def meth(self): return "A"
   3 class B(object):
   4     def meth(self): return "B"
   5 
   6 class X(A, B): pass
   7 class Y(B, A): pass
   8 
   9 class Z(X, Y): pass

De acordo com o algoritmo acima, a ordem de resolução de métodos de Z deveria ser [Z, X, Y, B, A, object], mas se você verificar isso em Python 2.2, usando Z.__mro__, você terá [Z, X, Y, A, B, object]! Numa versão futura duas coisas podem acontecer: a ordem de resolução de Z pode mudar para [Z, X, Y, B, A, object]; ou a declaração da classe Z pode se tornar ilegal, porque cria uma discordância de ordem; A classe A precede a classe B na lista de bases de X, mas sucede B na lista de bases de Y.

O livro "Putting Metaclasses to Work (não editado em português)", que me inspirou a alterar a MRO, define o algoritmo que está sendo usado atualmente, mas sua descrição é bem complicada de entender - eu nem percebi que o algoritmo não computava sempre a mesma ordem até que Tim Peters (http://www.python.org/tim_one/) encontrou um exemplo contrário. Felizmente, eles apenas ocorrem quando há outras discordâncias na hierarquia. O livro discrimina classes contendo tais discordâncias, se forem "sérias". Uma discordância de ordem entre duas classes é séria quando elas definem pelo menos um método com o mesmo nome, como no exemplo acima. Em Python 2.2, eu optei por não verificar esse tipo de discordância séria, mas o resultado de um programa fica indefinido, e isso pode mudar no futuro.

Métodos cooperativos e "super"

Uma das coisas mais legais, mas ao mesmo tempo mais estranhas em classes novas é a possibilidade de escrever classes "cooperativas". Essas classes são escritas pensando em herança múltipla, usando um padrão que eu chamo de "super chamada cooperativa". Isto é conhecido em outras linguagens e é mais poderoso que o tipo de super-chamada encontrada em linguagens com herança simples, como Java e Smalltalk. C++ não tem qualquer forma de super-chamada, utilizando um mecanismo explícito semelhante ao usado em classes tradicionais.

Para relembrar, vamos revisar as super-chamadas tradicionais, não cooperativas. Quando uma classe C deriva de uma classe B, C pode querer redefinir um método m definido em B. Uma "super-chamada" ocorre quando C.m chama B.m para realizar uma parte de seu trabalho. Em Java, C.m pode usar super(a, b, c) para chamar B.m com os argumentos (a, b, c). Em Python, C.m usa B.m(self, a, b, c) para atingir o mesmo objetivo. Por exemplo: 

   1 class B:
   2     def m(self):
   3         print "sou B"
   4 
   5 class C(B):
   6     def m(self):
   7         print "sou C"
   8         B.m(self)

Nós dizemos que o método C.m "extende" o método B.m. O padrão aqui mostrado funciona muito bem enquanto estivermos usando herança simples, mas não funciona com herança múltipla. Vamos olhar em quatro classes com uma hierarquia em forma de diamante, o mesmo da seção anterior: 

   1 class A(object): ..
   2 class B(A): ...
   3 class C(A): ...
   4 class D(B, C): ...

Suponha que A define um método m, que é extendido por ambas as classes B e C. Agora, como fica D? Tradicionalmente, Python simplesmente pega o primeiro atributo encontrado, neste caso, a definição de B. Isto não é bom pois ignora completamente C. Para entender o que está errado em ignorar C.m, imagine que estas classes representam alguma estrutura de dados persistente, e considerer que m é um método que implementa a operação "salve seus dados". Teoricamente, uma instância de D tem os dados de B e C, assim como A. Ignorar a definição de C do método "salvar" significa que uma instância de D, quando estiver salvando seus dados, salva apenas as partes A e B, mas não a parte definida por C!

Em C++, o compilador emite uma mensagem de erro avisando D herda duas verões conlitantes do método m. O autor de D então deve redefinir m para resolver o conflito. Mas o que a definição de m em D deve fazer? Ela pode chamar C.m e em seguida B.m, mas porque ambas chamam a definição de m herdada de A, A.m acaba sendo chamada duas vezes! Dependendo dos detalhes da operação, isto é no melhor dos casos uma ineficiência, no pior caso um erro. Tradicionalmente, Python tem o mesmo problema, exceto que nem considera um erro em pegar as duas versões conflitantes do método: simplesmente pega a primeira.

A solução tradicional para este dilema é dividir cada definição de m em duas partes: uma implementação parcial, _m, que apenas salva os dados que são únicos de cada classe, e uma implementação completa, m, que chama seu próprio _m e os das classes base. Por exemplo: 

   1 class A(object):
   2     def m(self): "salva A"
   3 class B(A):
   4     def _m(self): "salva B"
   5     def m(self):  self._m(); A.m(self)
   6 class C(A):
   7     def _m(self): "salva C"
   8     def m(self):  self._m(); A.m(self)
   9 class D(B, C):
  10     def _m(self): "salva D"
  11     def m(self):  self._m(); B._m(self); C._m(self); A.m(self)

Há diversos problemas com esse padrão. Primeiro, há a proliferação de métodos e chamadas extras. Talvez, mais importante que isso, ele cria uma dependência indesejável dos detalhes das classes base nas classes derivadas: a existência de A não pode mais ser considerada um detalhe de B e C, pois D precisa saber dela. Se numa futura versão do programa nós quisermos remover a dependência sobre A de B e C, isso afetará classes derivadas, como D; de forma semelhante, se nós quisermos adicionar outra classe base AA a B e C, todas suas classes derivadas terão de ser atualizadas.

O padrão "chame-o-método-seguinte" resolve este problema adequadamente, em combinação com a nova ordem de resolução de métodos. Aqui está: 

   1 class A(object):
   2     def m(self): "salva A"
   3 class B(A):
   4     def m(self): "salva B"; super(B, self).m()
   5 class C(A):
   6     def m(self): "salva C"; super(C, self).m()
   7 class D(B, C):
   8     def m(self): "salva D"; super(D, self).m()

Note que o primeiro argumento para super() é sempre a classe onde ele ocorre; o segundo argumento é sempre self. Note ainda que self não é repetida na lista de argumentos para m.

Agora, para poder explicar como super funciona, considere a MRO para cada uma das classes. A MRO é dada pelo atributo __mro__ da classe. 

   1 A.__mro__ == (A, object)
   2 B.__mro__ == (B, A, object)
   3 C.__mro__ == (C, A, object)
   4 D.__mro__ == (D, B, C, A, object)

A expressão super(C, self).m deve ser usada apenas dentro da implementação do método m na classe C. Tenha em mente que enquanto self é uma instância de C, self.__class__ pode não ser C: pode ser uma classe derivada de C (D, por exemplo). A expressão super(C, self).m, busca em self.__class__.__mro__ pela ocorrência de C, e então começa a procurar por uma implementação do método m a partir daquele ponto.

Por exemplo, se self é uma instância de C, super(C, self).m irá encontra a implementação de m em A, assim como super(B, self).m se self for uma instância de B. Mas agora considere uma instância de D. Em D.m, super(D, self).m() irá encontrar e chamar B.m(self), já que B é a primeira classe base depois de D em D.__mro__ que define um método m. Agora em B.m, super(B, self).m() é chamado. Como self é uma instância de D, a MRO é [D, B, C, A, object] e a classe seguindo B é C. É aqui que a busca por uma definição de m continua. Então encontramos C.m, que é chamado e por sua vez chama super(C, self).m(). Ainda usando a mesma MRO, nós vemos que a classe seguindo C é A e então A.m é chamado. Como esta é a definição original de m, nenhuma super chamada é feita neste ponto.

Note como a mesma expressão encontra uma classe diferente implementando o método! Essa é a essência do mecanismo coopoerativo.

No entanto, a super chamada mostrada acima está sujeita a erros: é fácil copiar e colar código de uma classe para outra e esquecer de mudar o nome da classe, e este erro não será detectado. (Você pode até mesmo causar recursão infinita passando por engano o nome de uma classe derivada da classe contendo a super chamada.) Seria bom se não tivéssemos de nomear explicitamente a classe, mas isso iria requerer mais ajuda do parser do que podemos obter atualmente. Eu espero poder corrigir isso no futuro, tornando o parser capaz reconhecer super().

Neste meio tempo, aqui está um truque que você pode aplicar. Nós podemos criar uma variável da classe nomeada __super que tem efeito de "ligação". (Este é um novo conceito em Python 2.2, mas formaliza um conceito bem conhecido em versões anteriores: a transformação de um método desligado para um método ligado quando ele é acessado através de getattr em uma instância. É implementado pelo método __get__ discutido acima. Aqui está um exemplo simples: 

   1 class A:
   2     def m(self): "salva A"
   3 class B(A):
   4     def m(self): "salva B"; self.__super.m()
   5 B._B__super = super(B)
   6 class C(A):
   7     def m(self): "salva C"; self.__super.m()
   8 C._C__super = super(C)
   9 class D(B, C):
  10     def m(self): "salva D"; self.__super.m()
  11 D._D__super = super(D)

Parte do truque está no uso do nome __super, que (através da transformação do nome) passa a conter o nome da classe. Isso assegura que self.__super tem um significado diferente em cada classe (enquanto os nomes das classes foram diferentes; infelizmente, é possível em Python reusar o nome de uma classe base para uma classe derivada). Outra parte do truque está no fato de que super pode ser chamada com um único argumento, e criar uma versão desligada que pode ser ligada depois através da operação getattr de uma instância.

Infelizmente, este exemplo ainda não é o ideal, por uma série de razões: super requer que a classe seja passada, mas a classe ainda não está disponivel até que a execução da definição da classe seja concluída, então, o atributo __super tem de ser criado fora da classe. Fora da classe, a tranformação do nome não ocorre, então a definição tem de usar o nome já transformado. Felizmente, é possível escrever uma metaclasse que automaticamente adiciona um atributo __super a suas classes; veja o exemplo da metaclasse autosuper logo abaixo.

Note que super(classe, subclasse) também funciona; isso é necessário para __new__ e outros métodos estáticos.

Exemplo: escrevendo super() em Python

Para ilustrar o poder do novo sistema, aqui está uma implementação completa da classe super() em Python pura. Isso pode ajudar a compreender melhor a semântica de super(), mostrando a busca em detalhes. O print no final do código mostra "DCBA". 

   1 class Super(object):
   2     def __init__(self, type, obj=None):
   3         self.__type__ = type
   4         self.__obj__ = obj
   5     def __get__(self, obj, type=None):
   6         if self.__obj__ is None and obj is not None:
   7             return Super(self.__type__, obj)
   8         else:
   9             return self
  10     def __getattr__(self, attr):
  11         if isinstance(self.__obj__, self.__type__):
  12             starttype = self.__obj__.__class__
  13         else:
  14             starttype = self.__obj__
  15         mro = iter(starttype.__mro__)
  16         for cls in mro:
  17             if cls is self.__type__:
  18                 break
  19         # Nota: mro é um iterador, então o segundo loop
  20         # continua onde o primeiro parou
  21         for cls in mro:
  22             if attr in cls.__dict__:
  23                 x = cls.__dict__[attr]
  24                 if hasattr(x, "__get__"):
  25                     x = x.__get__(self.__obj__)
  26                 return x
  27         raise AttributeError, attr
  28 
  29 class A(object):
  30     def m(self):
  31         return "A"
  32 
  33 class B(A):
  34     def m(self):
  35         return "B" + Super(B, self).m()
  36 
  37 class C(A):
  38     def m(self):
  39         return "C" + Super(C, self).m()
  40 
  41 class D(C, B):
  42     def m(self):
  43         return "D" + Super(D, self).m()
  44 
  45 print D().m() # "DCBA"

Redefinindo o método __new__

Quando derivamos de tipos imutáveis, como números e strings, e ocasionalmente em outras situações, o método estático __new__ pode ser bem útil. __new__ é o primeiro passo da construção de instâncias, chamado antes de __init__. O método __new__ é chamado com a classe como primeiro argumento; sua responsabilidade é retornar uma nova instância daquela classe. Compare isso com __init__: __init__ é chamado com uma instância como primeiro argumento, e não returna nada; sua responsabilidade é inicializar a instância. Há situações onde uma instância é criada sem chamar __init__ (por exemplo, quando é carregada com pickle). Não há maneira de criar uma nova instância sem chamar __new__ (apesar de em alguns casos você poder chamar o __new__ de uma classe base).

Lembre-se que criamos instâncias chamando a classe. Quando a classe é uma classe "new-style", ocorre o seguinte durante essa chamada. Primeiro, o método __new__ da classe é chamado, passando a classe como primeiro argumento, seguido de quaisquer argumentos recebidos pela chamada original. Isto retorna uma nova instância. Então o método __init__ da instância é chamado para inicializá-la. (Tudo isso é controlado pelo método __call__ da metaclasse.)

Segue aqui um exemplo de uma subclasse que redefine __new__ - é assim que você irá normalmente usá-lo. 

>>> class inch(float):
...     "Converte de polegadas para metros"
...     def __new__(cls, arg=0.0):
...         return float.__new__(cls, arg*0.0254)
...
>>> print inch(12)
0.3048
>>>

Essa classe não é muito útil (nem é a maneira correta de converter unidades) mas mostra como extender o método construtor de um tipo imutável. Se ao invés de __new__ nós tentarmos redefinir __init__, não funcionaria. 

>>> class inch(float):
...     "NÃO FUNCIONA!!!"
...     def __init__(self, arg=0.0):
...         float.__init__(self, arg*0.0254)
...
>>> print inch(12)
12.0
>>>

A versão redefinido __init__ não funciona porque o método __init__ do tipo flolat é um no-op: ele retorna imediatamente, ignorando seus argumentos.

Isso existe para que tipos imutáveis possam preservar sua imutabilidade, mas permitindo a criação de subclasses. Se o valor de um objeto float fosse inicializado por __init__, você poderia mudar o valor de um objeto existente! Por exemplo, isto funcionaria: 

>>> # NÃO FUNCIONA!
>>> import math
>>> math.pi.__init__(3.0)
>>> print math.pi
3.0
>>>

Esse problema poderia ser solucionado de outras formas, por exemplo, adicionando um marcador "inicializado" ou apenas permitindo que __init__ fosse chamado em instâncias de subclasses, mas estas soluções são inelegantes. Ao invés disso, adicionei __new__, que é um mecanismo perfeitamente genérico e pode ser usado por built-ins e classes definidas pelo usuário, por objetos mutáveis e imutáveis.

Algumas regras para __new__:

Como outro exemplo de __new__, aqui está uma forma de implementar o padrão singleton. 

   1 class Singleton(object):
   2     def __new__(cls, *args, **kwds):
   3         it = cls.__dict__.get("__it__")
   4         if it is not None:
   5             return it
   6         cls.__it__ = it = object.__new__(cls)
   7         it.init(*args, **kwds)
   8         return it
   9     def init(self, *args, **kwds):
  10         pass

Para criar uma classe singleton, você deriva de Singleton; cada subclasse terá uma única instância, não importa quantas vezes o construtor é chamado. Para inicializar a instância, subclasses devem redefinir init ao invés de __init__ - o método __init__ é chamada cada vez que o construtor é chamado. Por exemplo: 

>>> class MySingleton(Singleton):
...     def init(self):
...         print "chamando init"
...     def __init__(self):
...         print "chamando __init__"
...
>>> x = MySingleton()
chamando init
chamando __init__
>>> assert x.__class__ is MySingleton
>>> y = MySingleton()
chamando __init__
>>> assert x is y
>>>

Metaclasses

No passado, discussões sobre metaclasses em Python faziam cabelos se arrepiar e até mesmo cérebros explodirem (veja, por exemplo "Metaclasses in Python 1.5"). Felizmente, em Python 2.2, metaclasses são mais acessíveis e menos perigosas.

Terminologicamente falando, uma metaclasse é simplesmente "a classe de uma classe". Qualquer classe cujas instâncias sejam outras classes, é uma metaclasse. Quando falamos de instâncias que não sejam classes, a metaclasse da instância é a classe de sua classe: por definição a metaclasse de x é x.__class__.__class__. Mas quando falamos de uma classe C, nós frequentemente nos referimos a sua metaclasse quando falamos C.__class__ (não C.__class__.__class__ que seria uma meta-metaclasse).

O built-in 'type' é a a metaclasse mais comum; é a metaclasse de todos os built-ins. Classes tradicionais usam uma metaclasse diferente; types.ClassType, que é relativamente desinteressante; é um artefato histórico necessário para que classes tradicionais tenham seu comportamente. Você não pode chegar a metaclasse de uma instância de uma classe tradicional usando x.__class__.__class__; você tem de usar type(x.__class__), porque classes tradicionais não suportam o atributo __class__ em classes (apenas em instâncias).

Quando uma definição de classe é executada, o interpretador primeiro determina a metaclasse apropriada, que chamaremos de M, e então chama M(nome, bases, dict). Tudo isso ocorre no fim da definição de classe, depois do corpo da classe (onde métodos e variáveis de classe são definidos) ter sido executado. Os argumentos para M são o nome da classe (uma string retirada da definição da classe), um tuple de classes base (expressões executadas no início da definição de classe), e um dicionário contendo os métodos e variáveis de classe. Qualquer coisa que essa chamada M(nome, bases, dict) retorne é então referenciado pela variável correspondente ao nome da classe.

Como M é determinada?

O mais comum é que M seja ou types.ClassType (criando uma classe tradicional) ou 'type' (criando uma classe "new-style", ou tipo). Outros possíveis são um tipo de uma extensão personalizada (como a ExtensionClass de Jim Fulton), ou um subtipo de 'type' (quando nós usamos metaclasses "new-style"). Mas é possível ter algo completamente diferente aqu: se espeficicarmos uma classe base com um atributo __class__ modificado, podemos usar qualquer coisa como uma metaclasse. Este era o tópico que explodia cérebros no meu artigo original, e não irei repeti-lo aqui.

Há sempre algum detalhe adicional. Quando você mistura classes tradicionais e "new-style" na lista de classes base, a metaclasse da primeira classe "new-style" é usada ao invés de types.ClassType (assumindo que dict['__metaclass__'] está indefinida). O efeito é que quando você cruza uma classe tradicional e uma "new-style" o resultado é uma classe "new-style".

Um outro detalhe. Para metaclasses, há uma restrição que a metaclasse escolhida seja igual ou uma subclasse de cada uma das metaclasses das suas classes base. Considere uma classe C com duas classes base, B1 e B2. Digamos que M = C.__class__, M1 = B1.__class__, M2 = B2.__class__. Então é necessário que issubclass(M, M1) e issubclass(M, M2). (Isso ocorre porque um método de B1 deve ser capaz de chamar um meta-método definido em M1 em self.__class__, mesmo que self seja uma instância de uma subclasse de B1).

(nota do tradutor: esse parágrafo foi bem complicado de entender no original, então escrevi o código para facilitar a compreensão do problema: 

>>> class M(type): pass
...
>>> class M1(type): pass
...
>>> class M2(type): pass
...
>>> class B1:
...     __metaclass__ = M1
...
>>> class B2:
...     __metaclass__ = M2
...
>>> class C(B1, B2):
...     __metaclass__ = M
...
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: metaclass conflict: the metaclass of a derived cl
ass must be a (non-strict) subclass of the metaclasses of al
l its bases
>>>

Em outras palavras, se você uma classe C, que tem por metaclasse M e é subclasse de B1 e B2, que têm por metaclasses M1 e M2 respectivamente, é necessário que M seja uma subclasse de todas as metaclasses das classes base. Complicado ?)

O livro "Putting Metaclasses to Work" descreve um mecanismo em que uma submetaclasse de M1 e M2 é automaticamente gerada quando necessário. Em Python 2.2 eu optei por uma solução mais simples que simplesmente gera um erro se a restrição da submetaclasse não for satisfeita; é responsabilidade do programador prover uma metaclasse adequada através da variável __metaclass__ da classe. No entanto, se uma das metaclasses base satisfaz a restrição (incluindo a __metaclass__ passada explicitamente, se for o caso), a primeira metaclasse base que satisfizer a restrição será usada como metaclasse.

Na prática, isso significa que se você tiver uma hierarquia degenerada de metaclasses que tenha o formato de uma torre (para cada duas metaclasses M1 e M2, pelo menos um entre issubclass(M1, M2) ou issubclass(M2, M1) é sempre verdadeiro), você não tem de se preocupar com essa restrição. Por exemplo: 

   1 # Metaclasses
   2 class M1(type): ...
   3 class M2(M1): ...
   4 class M3(M2): ...
   5 class M4(type): ...
   6 
   7 # Classes
   8 class C1:
   9     __metaclass__ = M1
  10 class C2(C1):
  11     __metaclass__ = M2
  12 class C3(C1, C2):
  13     __metaclass__ = M3
  14 class D(C2, C3):
  15     __metaclass__ = M1
  16 class C4:
  17     __metaclass__ = M4
  18 class E(C3, C4):
  19     pass

Para a classe C2, a restrição é satisfeita porque M2 é uma subclasse de M1. Para a classe C3, é satisfeita porque M3 é uma subclasse de ambas M1 e M2. Para a classe D, a metaclasse explícita M1 não é uma subclasse de ambas M1 e M2, mas M3 satisfaz a restrição, então D.__class__ é M3. No entanto, a classe E é um erro: as duas metaclasses envolvidas são M3 e M4, e nenhuma deles é uma subclasse da outra. Nós podemos corrigir isso da seguinte forma. 

   1 # Uma nova metaclasse
   2 class M5(M3, M4): pass
   3 
   4 # Classe E corrigida
   5 class E(C3, C4):
   6     __metaclass__ = M5

Exemplos de Metaclasses

Vamos relembrar um pouco de teoria primeiro. Lembre-se que uma definição de classe gera uma chamada para M(name, bases, dict), onde M é a metaclasse. Agora, uma metaclasse é uma classe e nós já definimos que quando uma classe é executada, seus métodos __new__ e __init__ são chamados em sequência. Então, algo como isso ocorre: 

   1 cls = M.__new__(M, name, bases, dict)
   2 assert cls.__class__ is M
   3 M.__init__(cls, name, bases, dict)

Eu estou escrevendo a chamada a __init__ aqui como um método "unbound". Isso deixa claro que estamos chamando o __init__ da metaclasse M, não o da classe cls (que seria a inicialização das instâncias de cls). É claro que no fundo, ele realmente chama o __init__ de cls, que por um acaso é a classe.

Nosso primeiro exemplo é uma metaclasse que procura entre os atributos de uma classe por métodos chamados _get_algumas_coisa e _set_alguma_coisa e automaticamente adiciona propriedades nomeados "alguma_coisa" para eles. É suficiente sobrescrever apenas __init__ para fazer o que queremos. Também chamamos o __init__ da classe base de forma cooperativa, usando super(). 

   1 class autoprop(type):
   2     def __init__(cls, name, bases, dict):
   3         super(autoprop, cls).__init__(name, bases, dict)
   4         props = {}
   5         for name in dict.keys():
   6             if name.startswith("_get_") or name.startswith("_set_"):
   7                 props[name[5:]] = 1
   8         for name in props.keys():
   9             fget = getattr(cls, "_get_%s" % name, None)
  10             fset = getattr(cls, "_set_%s" % name, None)
  11             setattr(cls, name, property(fget, fset))

Aqui testamos autoprop com um exemblo bobo :). Uma classe que armazena um atributo x e seu valor invertido em self.__x: 

   1 class InvertedX:
   2     __metaclass__ = autoprop
   3     def _get_x(self):
   4         return -self.__x
   5     def _set_x(self, x):
   6         self.__x = -x
   7 
   8 a = InvertedX()
   9 assert not hasattr(a, "x")
  10 a.x = 12
  11 assert a.x == 12
  12 assert a._InvertedX__x == -12

Nosso segundo exemplo é uma classe 'autosuper', que irá adicionar variáveis privadas com o nome de __super, apontando para super(cls). (lembra-se da discussão sobre self.__super logo acima?). Lembre-se que __super é uma variável privada (começa com __), mas nós queremos que seja uma variável privada da classe a ser criada, não de autosuper. Então nós temos de converter o nome da variável nós mesmos, e usar setattr() para definí-lo na classe. Apenas para este exemplo, eu estou simplificando a conversão de nomes para simplesmente "adicionar um underscore ao nome da classe". Novamente, apenas __init__ é suficiente para fazer o que queremos, e fazemos a chamada ao __init__ da classe base cooperativamente, usando super(). 

   1 class autosuper(type):
   2     def __init__(cls, name, bases, dict):
   3         super(autosuper, cls).__init__(name, bases, dict)
   4         setattr(cls, "_%s__super" % name, super(cls))

Agora, testando autosuper com o clássico diagrama em forma de diamante: 

   1 class A:
   2     __metaclass__ = autosuper
   3     def meth(self):
   4         return "A"
   5 class B(A):
   6     def meth(self):
   7         return "B" + self.__super.meth()
   8 class C(A):
   9     def meth(self):
  10         return "C" + self.__super.meth()
  11 class D(C, B):
  12     def meth(self):
  13         return "D" + self.__super.meth()
  14 
  15 assert D().meth() == "DCBA"

(Nossa metaclasse autosuper é facilmente enganada se você definir uma subclasse com o mesmo nome de uma classe base; ela deveria verificar essa condição e gerar um erro se isso ocorrer. No entanto, isso seria muito mais código do que eu acho certo para um exemplo, então vou deixar como exercício para o leitor.)

Agora que nós temos duas metaclasses desenvolvidas independentemente, podemos combiná-las em uma terceira submetaclasse de ambas. 

   1 class autosuprop(autosuper, autoprop):
   2     pass

Simples, não? Como nós criamos ambas as metaclasses cooperativamente (usando super() para chamar os métodos da classe base), isso é tudo que precisamos. Agora vamos testá-la. 

   1 class A:
   2     __metaclass__ = autosuprop
   3     def _get_x(self):
   4         return "A"
   5 class B(A):
   6     def _get_x(self):
   7         return "B" + self.__super._get_x()
   8 class C(A):
   9     def _get_x(self):
  10         return "C" + self.__super._get_x()
  11 class D(C, B):
  12     def _get_x(self):
  13         return "D" + self.__super._get_x()
  14 
  15 assert D().x == "DCBA"

Isso é tudo por hoje. Espero que sua cabeça não esteja doendo muito !

Incompatibilidades

Relaxe! A maior parte do que foi descrito aqui só é usado quando você define uma classe com um built-in como classe base (ou quando usando explicitamente o argumento __metaclass__).

Algumas coisas que podem afetar código existente. Veja também a lista de bugs na versão 2.2. 

   1 class A:
   2     def foo(self): pass
   3 
   4 class B(A): pass
   5 
   6 class C(A):
   7     def foo(self):
   8         B.foo(self)

Referências

Traduzido por PedroWerneck

UnificandoTiposClasses (editada pela última vez em 2008-09-26 14:07:46 por localhost)