Devo usar uma aula ou dicionário?

Eu tenho uma classe que contém apenas campos e nenhum método, como este:

class Request(object):

    def __init__(self, environ):
        self.environ = environ
        self.request_method = environ.get('REQUEST_METHOD', None)
        self.url_scheme = environ.get('wsgi.url_scheme', None)
        self.request_uri = wsgiref.util.request_uri(environ)
        self.path = environ.get('PATH_INFO', None)
        # ...

Isso poderia ser facilmente traduzido para um dict. A classe é mais flexível para adições futuras e pode ser mais rápida __slots__. Então, haveria uma vantagem em usar um dicionário em vez disso? Um dict seria mais rápido do que uma aula? E mais rápido do que uma classe com slots?

Por que você faria este dicionário? Qual é a vantagem? O que acontece se você quiser adicionar algum código posteriormente? Para onde iria seu __init__código?

As aulas são para agrupar dados relacionados (e geralmente código).

Os dicionários são para armazenar relacionamentos de valor-chave, onde geralmente as chaves são todas do mesmo tipo e todos os valores também são de um tipo. Ocasionalmente, eles podem ser úteis para agrupar dados quando os nomes de chave / atributo não são todos conhecidos antecipadamente, mas geralmente isso é um sinal de que algo está errado com seu projeto.

Mantenha esta uma aula.

Use um dicionário, a menos que você precise do mecanismo extra de uma classe. Você também pode usar um namedtuplepara uma abordagem híbrida:

>>> from collections import namedtuple
>>> request = namedtuple("Request", "environ request_method url_scheme")
>>> request
<class '__main__.Request'>
>>> request.environ = "foo"
>>> request.environ
'foo'

As diferenças de desempenho aqui serão mínimas, embora eu ficaria surpreso se o dicionário não fosse mais rápido.

Uma classe em python é um dict por baixo. Você obtém alguma sobrecarga com o comportamento da classe, mas não será capaz de notá-lo sem um criador de perfil. Nesse caso, acredito que você se beneficia com a aula porque:

• Toda a sua lógica vive em uma única função
• É fácil de atualizar e permanece encapsulado
• Se você mudar alguma coisa depois, pode facilmente manter a interface igual

Eu acho que o uso de cada um é muito subjetivo para eu entrar nisso, então vou me limitar aos números.

Eu comparei o tempo que leva para criar e alterar uma variável em um dicionário, uma classe new_style e uma classe new_style com slots.

Aqui está o código que usei para testá-lo (é um pouco confuso, mas faz o trabalho).

import timeit

class Foo(object):

    def __init__(self):

        self.foo1 = 'test'
        self.foo2 = 'test'
        self.foo3 = 'test'

def create_dict():

    foo_dict = {}
    foo_dict['foo1'] = 'test'
    foo_dict['foo2'] = 'test'
    foo_dict['foo3'] = 'test'

    return foo_dict

class Bar(object):
    __slots__ = ['foo1', 'foo2', 'foo3']

    def __init__(self):

        self.foo1 = 'test'
        self.foo2 = 'test'
        self.foo3 = 'test'

tmit = timeit.timeit

print 'Creating...\n'
print 'Dict: ' + str(tmit('create_dict()', 'from __main__ import create_dict'))
print 'Class: ' + str(tmit('Foo()', 'from __main__ import Foo'))
print 'Class with slots: ' + str(tmit('Bar()', 'from __main__ import Bar'))

print '\nChanging a variable...\n'

print 'Dict: ' + str((tmit('create_dict()[\'foo3\'] = "Changed"', 'from __main__ import create_dict') - tmit('create_dict()', 'from __main__ import create_dict')))
print 'Class: ' + str((tmit('Foo().foo3 = "Changed"', 'from __main__ import Foo') - tmit('Foo()', 'from __main__ import Foo')))
print 'Class with slots: ' + str((tmit('Bar().foo3 = "Changed"', 'from __main__ import Bar') - tmit('Bar()', 'from __main__ import Bar')))

E aqui está a saída ...

Criando ...

Dict: 0.817466186345
Class: 1.60829183597
Class_with_slots: 1.28776730003

Alterando uma variável ...

Dict: 0.0735140918748
Class: 0.111714198313
Class_with_slots: 0.10618612142

Então, se você está apenas armazenando variáveis, você precisa de velocidade e não vai exigir que você faça muitos cálculos, eu recomendo usar um dicionário (você pode apenas fazer uma função que se pareça com um método). Mas, se você realmente precisa de classes, lembre-se - sempre use __ slots __ .

Nota:

Testei a 'Classe' com as classes new_style e old_style. Acontece que as classes old_style são mais rápidas de criar, mas mais lentas de modificar (não muito, mas significativo se você estiver criando muitas classes em um loop fechado (dica: você está fazendo isso errado)).

Além disso, os tempos para criar e alterar variáveis ​​podem ser diferentes no seu computador, pois o meu é antigo e lento. Certifique-se de testar você mesmo para ver os resultados 'reais'.

Editar:

Posteriormente, testei o namedtuple: não posso modificá-lo, mas para criar os 10.000 exemplos (ou algo parecido) demorou 1,4 segundos, então o dicionário é realmente o mais rápido.

Se eu alterar a função dict para incluir as chaves e valores e retornar o dict em vez da variável que contém o dict quando eu crio, isso me dá 0,65 em vez de 0,8 segundos.

class Foo(dict):
    pass

Criar é como uma classe com slots e alterar a variável é o mais lento (0,17 segundos), portanto , não use essas classes . vá para um dict (velocidade) ou para a classe derivada do objeto ('doce de sintaxe')

Eu concordo com @adw. Eu nunca representaria um "objeto" (no sentido OO) com um dicionário. Os dicionários agregam pares de nome / valor. As classes representam objetos. Eu vi um código onde os objetos são representados com dicionários e não está claro qual é a forma real da coisa. O que acontece quando certos nomes / valores não estão lá? O que restringe o cliente de colocar qualquer coisa dentro. Ou de tentar retirar qualquer coisa. A forma da coisa sempre deve ser claramente definida.

Ao usar Python, é importante construir com disciplina, pois a linguagem permite que o autor dê um tiro no próprio pé de várias maneiras.

Eu recomendaria uma aula, pois são todos os tipos de informações envolvidas em uma solicitação. Se alguém usasse um dicionário, esperaria que os dados armazenados fossem muito mais semelhantes em natureza. Uma orientação que eu mesmo tendo a seguir é que, se quiser fazer um loop por todo o conjunto de pares chave-> valor e fazer algo, uso um dicionário. Caso contrário, os dados aparentemente têm muito mais estrutura do que um mapeamento básico de chave-> valor, o que significa que uma classe provavelmente seria uma alternativa melhor.

Portanto, fique com a classe.

Se tudo o que você deseja alcançar é um doce de sintaxe em obj.bla = 5vez de obj['bla'] = 5, especialmente se tiver que repetir muito isso, talvez queira usar alguma classe de contêiner simples como na sugestão de martineaus. No entanto, o código lá é bastante inchado e desnecessariamente lento. Você pode mantê-lo simples assim:

class AttrDict(dict):
    """ Syntax candy """
    __getattr__ = dict.__getitem__
    __setattr__ = dict.__setitem__
    __delattr__ = dict.__delitem__

Outro motivo para mudar para namedtuples ou uma classe __slots__pode ser o uso de memória. Os dictos exigem muito mais memória do que os tipos de lista, portanto, esse pode ser um ponto a se pensar.

De qualquer forma, no seu caso específico, não parece haver nenhuma motivação para abandonar sua implementação atual. Você não parece manter milhões desses objetos, portanto, nenhum tipo derivado de lista é necessário. E, na verdade, contém alguma lógica funcional dentro do __init__, então você também não deve continuar AttrDict.

Pode ser possível ter seu bolo e comê-lo também. Em outras palavras, você pode criar algo que forneça a funcionalidade de uma classe e de uma instância de dicionário. Veja a receita Dɪᴄᴛɪᴏɴᴀʀʏ ᴡɪᴛʜ ᴀᴛᴛʀɪʙᴜᴛᴇ-sᴛʏʟᴇ ᴀᴄᴄᴇss do ActiveState e comentários sobre as maneiras de fazer isso.

Se você decidir usar uma classe regular em vez de uma subclasse, descobri que a receita Tʜᴇ sɪᴍᴘʟᴇ ʙᴜᴛ ʜᴀɴᴅʏ "ᴄᴏʟʟᴇᴄᴛᴏʀ ᴏғ ᴀ ʙᴜɴᴄʜ ᴏғ ɴᴀᴍᴇᴅ sᴛᴜғғ" ᴄʟᴀss (de Alex Martelli) é muito flexível e útil para o tipo de coisa que parece que você está fazendo (ou seja, criar um agregador de informações relativamente simples). Por ser uma classe, você pode facilmente estender sua funcionalidade ainda mais adicionando métodos.

Por último, deve-se observar que os nomes dos membros da classe devem ser identificadores legais do Python, mas as chaves de dicionário não - portanto, um dicionário forneceria maior liberdade a esse respeito porque as chaves podem ser qualquer coisa hashble (mesmo algo que não seja uma string).

Atualizar

Uma classe object(que não tem uma __dict__) subclasse chamada SimpleNamespace(que tem uma) foi adicionada ao typesmódulo Python 3.3 e é mais uma alternativa.

class ClassWithSlotBase:
    __slots__ = ('a', 'b',)

def __init__(self):
    self.a: str = "test"
    self.b: float = 0.0


def test_type_hint(_b: float) -> None:
    print(_b)


class_tmp = ClassWithSlotBase()

test_type_hint(class_tmp.a)

Eu recomendo uma aula. Se você usar uma classe, poderá obter uma dica de tipo conforme mostrado. E a classe oferece suporte à conclusão automática quando a classe é um argumento de função.