Don't use __slots__ (was Re: Problem of Readability of Python)

Diez B. Roggisch deets at
Mon Oct 8 15:15:36 CEST 2007

Steven D'Aprano wrote:

> On Sun, 07 Oct 2007 21:27:31 -0700, Aahz wrote:
>> In article <2tqdncU0D6K8v5TanZ2dnUVZ_hGdnZ2d at>, Steven
>> Bethard  <steven.bethard at> wrote:
>>>You can use __slots__  [...]
>> Aaaugh!  Don't use __slots__!
>> Seriously, __slots__ are for wizards writing applications with huuuge
>> numbers of object instances (like, millions of instances).  For an
>> extended thread about this, see
> thread/8775c70565fb4a65/0e25f368e23ab058
> Well, I've read the thread, and I've read the thread it links to, and for
> the life of me I'm still no clearer as to why __slots__ shouldn't be used
> except that:
> 1 Aahz and Guido say __slots__ are teh suxxor;
> 2 rumour (?) has it that __slots__ won't make it into Python 3.0;
> 3 inheritance from classes using __slots__ doesn't inherit the slot-
> nature of the superclass.
> Point 1 is never to be lightly dismissed, but on the other hand Guido
> doesn't like reduce(), and I'm allergic to "Cos I Said So" arguments.
> History is full of things which were invented for one purpose being used
> for something else. So, that being the case, suppose I accept that using
> __slots__ is not the best way of solving the problem, and that people of
> the skill and experience of Guido and Aahz will roll their eyes and
> snicker at me.
> But is there actually anything *harmful* that can happen if I use
> __slots__?

Point 3 clearly is harmful. As is the fact that __slots__ gives you troubles
if you e.g. pass objects to code that tries to set arbitrary attributes on
an object. While this might be frowned upon, it can be useful in situations
where you e.g. link GUI-code/objects with data-objects: instead of creating
cumbersome, explicit mappings (as you have to in C/C++/Java) or wrappers,
just set a well-named property.

The question is: what does a slot buy you for this kind of problem? And
while arguing with "then I can't set an attribute I didn't want to be set"
is certainly possible, it ultimately leads to the darn
static-vs-dynamic-discussion. Which we might spare us this time.


More information about the Python-list mailing list