__slots_ and inheritance

[Andrew Dalke]

Martelli-bot:
> Still, it DOES mention, as the
> one and only claimed advantage, that, without __slots__, "using a
> separate dictionary to hold a single instance variable doubles the
> memory used", and then proceeds to list the resulting limitations
> as "tidbits and warnings".  Any different reading is clearly wishful
> thinking, and the design intent seems pretty clear here.

I was recently looking at a Python package ported from Java.
It was the first package I've reviewed which used __slots__.
My impression is that __slots__ were used as a rough approximation
to declaring instance attributes, and not because of an explicit desire
to save space or improve lookup performance.  (That desire may
be implicit, but given the early state of the code it would be
premature to act on it.)

Given the style of the code, it appears that the author is not an
experienced programmer (eg, used "if flag is True" rather than
"if flag"), which I believe back my belief that people from statically
type languages look for a way to declare attributes, find __slots__,
and use it, not really knowing the appropriateness of this approach.

This is different than the design intent.  Should the documentation
be updated to caution against using __slots__ except for cases
which fit better the original intent? ....

> > 1. what's the point of not automatically including a slot for
> > '__weakref__'
> >    (hardly the unreasonable memory consumption such a slot would
impose?)?
>
> Indeed definitely that -- increasing memory consumption by e.g. 50%
> for an object with two "true" slots, just in case somebody in the
> future MAY want to weakreference it, would be a weird choice.  If
> you need your instances to be weakly referenceable include the slot
> explicitly and pay the attendand memory price.

I don't know __slots__ well enough.  Does you mean that if I want
weak references for these I can simply add that slot, as in

  __slots__ = [..., "__weakref__"]
?

> Sure.  So what?  A trickily coded class could always throw introspection
> based on instance __dict__ off -- __getattr__ could and often did "add"
> attributes not otherwise visible.

Though it should have also implemented __methods__ and/or __members__,
to return the list of otherwise invisible fields.

Very few __getattr__ implementation did this.  It's documented, but hard
to tell when/why it's useful.

Regarding Alexander Schmolck's post upon which Alex Martelli is
commenting -- Peering at the __dict__ is also problematical because
it didn't find class attributes.

>>> class Spam:
...  spam = 1
...
>>> dir(Spam())
['__doc__', '__module__', 'spam']
>>> Spam().__dict__
{}
>>>

                    Andrew
                    dalke at dalkescientific.com