The _total_size thing looks like a wildly bad idea to me, since it's so poorly defined (and relying on a couple of special cases). Also, "currsize" is quite bizarre. Why not simply "size"?
> Updated to use ABCs but still relies on user objects implementing > __sizeof__. So it is accurate whenever sys.getsizeof() is accurate. I'm really -1 on this. It's better to give no measurement than to give a totally wrong indication. The fact that you had to special-case containers shows that getsizeof() is *not* the right solution for this. (because if it was, you could rely on the containers' __sizeof__ instead of overriding it) The "size of an object and its contents" generally doesn't make any sense, because the object graph is massively connected. getsizeof() gives you the basic internal footprint of the object, but that's all. It's really not a high-level tool for the everyday programmer, and relying on it to say how much memory would be saved by getting rid of certain objects is bogus.
Indeed, getsizeof() on containers only gives the amount of memory consumed by the container itself (this can be difficult to figure out externally for potentially sparse containers like dicts), but leaves the question of the size of the referenced objects open. Exposing the result of sys.getsizeof() on the cache may not be a bad idea, but the question would be which use cases are handled by that additional information which aren't adequately covered by the simple count of the cache entries.
