[Python-Dev] Why aren't more things weak referencable

Raymond Hettinger python at rcn.com
Sun May 30 03:52:57 EDT 2004


[Raymond Hettinger]
> >> Instances of classes inheriting from str, tuple, etc cannot be
weakly
> >> referenced.  Does anyone know the reason for this?

[Bob Ippolito]
> > They can not accept non-empty __slots__ either, which is probably
closer
> > to the source of the problem.  I have no idea what the reason is.  I
> > imagine it's something to do with optimization, and/or because they
are
> > immutable.

[Christian Tismer]
> it is because they are var-sized objects. There is no place
> to put the weakref pointer in, since the variable part
> starts right at the beginning of the object.

Thanks.  That exactly identifies the issue.  It also explains the
mystery of why unicode subclasses are weakly referencable but str
subclasses are not.

For strings at least, perhaps it is time to bite the bullet and include
weak reference support directly.  Weak reference support ups the per
string memory overhead from five words (ob_type, ob_refcnt, ob_size,
ob_shash, ob_sstate) to six.  The whole concept of weak  dictionaries is
much more useful when strings can be used as keys and/or values.

Several other objects probably also warrant weak reference support:
array.array, files, sockets, and sre.pattern_objects.  In these cases,
the one word overhead is small relative to the rest of the object

Tuples would also be nice but the overhead is likely not worth it.
Chris's solution (recognizing that var sized objects are typically fixed
upon creation) is more general and doesn't burden the most common case.


Raymond




More information about the Python-Dev mailing list