Don't use __slots__ (was Re: performance of dictionary lookup vs. object attributes)

[Patrick Maupin]

skip at pobox.com wrote:
> Aahz> Taking a look at __slots__ is fine as long as you don't actually
>     Aahz> use them.
>
>     Gabriel> Why?
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/451ad25f9c648404/f4ac2dfde32b16fd?lnk=st&q=Python+__slots__+aahz&rnum=2#f4ac2dfde32b16fd
>
> Skip

The subject of __slots__ really seems to get some people's dander up,
to the extent where the heat/light ratio in the discussion becomes
uncomfortably high.  Right here, we have Skip referring to a post by
Aahz, where Aahz says that Guido says that slots are bad mojo, without
anybody ever giving concrete examples about why this may be the case.
The only assertion that was made explicitly enough to be testable came
about in a followup to Aahz's original post, only AFTER someone asked
what the side-effects associated with __slots__ were.  Aahz responded:

> The main one is that inheritance becomes difficult to nearly-impossible.

But this statement is either wrong or incomplete.  Classes can
certainly inherit from other classes which define __slots__, and this
statement doesn't describe the problems well enough for any reader to
figure out whether those problems directly affect him or not.  The only
problem I personally know of is that the __slots__ aren't inherited,
but if you just view slots as a storage optimization, that's not a
terrible thing.  Also, with duck-typing, inheritance isn't necessarily
all that important for many classes of classes, even if you take the
limited view that all programming is object-oriented.

I can certainly imagine that __slots__ do not give anywhere near the
benefit that was envisioned when they were first implemented, and I can
well believe that the implementation was, in retrospect, a "mistake".
It may well be that, in hindsight, the cost/benefit ratio was too high
to warrant having implemented them.

I can also believe that many people may see __slots__ and think "Aha!
This is how I implement type-checking!"  This is typically considered
unPythonic, so obviously when someone posts about how their
type-checking wasn't properly inherited when they subclassed an object,
a lot of heavy signing and gnashing of teeth will ensue.

So, since __slots__ shouldn't have been implemented (and since they may
not be implemented in Python 3000?) and since a lot of question about
__slots__ are in reference to problems they weren't intended to solve
in any case, it makes sense that people get testy about the whole
thing, but is that any reason to _always_ assert that an existing
languange feature should _never_ be used (and never back it up with
relevant concrete examples about the associated problems)?

My own experience with __slots__ has been quite positive, when I wanted
to create millions of instances of the same well-defined small object.
When the choices boil down to using __slots__ or dropping to C or
Pyrex, I'll take __slots__ every time, whether or not that is
Pythonically correct.  Now, if someone has a well-written technical
answer about how I might get bitten doing this, I would love to see it
(but "__slots__ might be removed later because it was a mistake, so
you'll have to rewrite your performance code in Pyrex anyway, so you
wasted the 5 minutes you spent adding __slots__ to some of your classes
two years ago" doesn't count).  If anybody ever wrote such a useful
answer, I missed it, so please give me a pointer to it!

For a similar, probably better-written, perspective, check out:
http://www.dalkescientific.com/writings/diary/archive/2006/03/19/class_instantiation_performance.html

Regards,
Pat