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

Guido van Rossum guido at python.org
Sun May 30 18:04:43 EDT 2004


> 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.

Hmm... it is a high price to pay to add another word (*and* some extra
code at dealloc time!) to every string object when very few apps need
them and strings are about the most common data type.  And since
they're immutable, what's the point of having weak refs to strings in
the first place?  (Note that the original poster asked about
*subclasses* of strings.)

> 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

These I have peace with.  Note that for sockets, the objects that
Python programs actually see are instances of a wrapper class defined
in Python (using __slots__ so to add weakrefs, you have to add
__weakreflist__ to the list of slots).

> 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.

I'm not sure how this observation helps.  Anyway, I have the same
concern for tuples as for strings.

--Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-Dev mailing list