每个python对象都有一个__dict__属性，它是一个包含所有其他属性的字典。例如，当你输入self时。Attr python实际上正在执行self.__dict__[' Attr ']。你可以想象使用字典来存储属性需要一些额外的空间和时间来访问它。

然而，当你使用__slots__时，为该类创建的任何对象都不会有__dict__属性。相反，所有属性访问都直接通过指针完成。

所以如果你想要一个C风格的结构而不是一个完整的类，你可以使用__slots__来压缩对象的大小并减少属性访问时间。一个很好的例子是一个包含属性x和y的Point类。如果你要有很多点，你可以尝试使用__slots__来节省一些内存。

除了其他答案，这里还有一个使用__slots__的例子:

>>> class Test(object):   #Must be new-style class!
...  __slots__ = ['x', 'y']
... 
>>> pt = Test()
>>> dir(pt)
['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', 
 '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', 
 '__repr__', '__setattr__', '__slots__', '__str__', 'x', 'y']
>>> pt.x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: x
>>> pt.x = 1
>>> pt.x
1
>>> pt.z = 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Test' object has no attribute 'z'
>>> pt.__dict__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Test' object has no attribute '__dict__'
>>> pt.__slots__
['x', 'y']

因此，要实现__slots__，它只需要额外的一行(并使您的类成为一个新样式的类，如果它还不是的话)。通过这种方式，您可以将这些类的内存占用减少5倍，代价是必须编写自定义pickle代码(如果需要的话)。

每个python对象都有一个__dict__属性，它是一个包含所有其他属性的字典。例如，当你输入self时。Attr python实际上正在执行self.__dict__[' Attr ']。你可以想象使用字典来存储属性需要一些额外的空间和时间来访问它。

然而，当你使用__slots__时，为该类创建的任何对象都不会有__dict__属性。相反，所有属性访问都直接通过指针完成。

所以如果你想要一个C风格的结构而不是一个完整的类，你可以使用__slots__来压缩对象的大小并减少属性访问时间。一个很好的例子是一个包含属性x和y的Point类。如果你要有很多点，你可以尝试使用__slots__来节省一些内存。

如果你要实例化很多(成百上千)同一个类的对象，你会想要使用__slots__。__slots__仅作为内存优化工具存在。

强烈建议使用__slots__来约束属性创建。

使用__slots__ pickle对象将无法使用默认的(最古老的)pickle协议;有必要指定一个更高的版本。

python的其他一些自省特性也可能受到不利影响。

插槽对于库调用非常有用，可以在进行函数调用时消除“命名方法分派”。SWIG文档中提到了这一点。对于想要减少常用调用函数的函数开销的高性能库来说，使用插槽要快得多。

这可能和OPs问题没有直接关系。它更多地与构建扩展有关，而不是与在对象上使用插槽语法有关。但它确实有助于完善插槽的使用情况以及它们背后的一些原因。

引用雅各布·海伦的话:

The proper use of __slots__ is to save space in objects. Instead of having a dynamic dict that allows adding attributes to objects at anytime, there is a static structure which does not allow additions after creation. [This use of __slots__ eliminates the overhead of one dict for every object.] While this is sometimes a useful optimization, it would be completely unnecessary if the Python interpreter was dynamic enough so that it would only require the dict when there actually were additions to the object. Unfortunately there is a side effect to slots. They change the behavior of the objects that have slots in a way that can be abused by control freaks and static typing weenies. This is bad, because the control freaks should be abusing the metaclasses and the static typing weenies should be abusing decorators, since in Python, there should be only one obvious way of doing something. Making CPython smart enough to handle saving space without __slots__ is a major undertaking, which is probably why it is not on the list of changes for P3k (yet).