Armin Rigo <ar...@users.sourceforge.net> added the comment: > The expectation is that it returns the memory footprint of the given > object, and only it (not taking into account sharing, caching, > dependencies or anything else).
It would be nice if this was a well-defined definition, but unfortunately it is not. For example, string objects may appear different from the user's point of view (e.g. as seen by id() and 'is') but share the implementation's data; they may even share only a part of it (if ropes are enabled). Conversely, for user-defined objects you would typically think not to count the "shape" information, which is usually shared among several instances -- but then you risk a gross under-estimation in the (rarer) cases where it is not shared. Another way to look at the "official" definition is to return the size of the object itself and none of its dependencies, because in theory they might be shared; but that would make all strings, lists, tuples, dicts, and so on have a getsizeof() of 8 or 12, which is rather useless. I hope this clarifies fijal's original comment: "it might be not well defined on other implementations." ---------- nosy: +arigo _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10994> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
