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/)