This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author arigo
Recipients arigo, brett.cannon, docs@python, fijall, lukasz.langa, pitrou
Date 2011-01-25.16:37:16
SpamBayes Score 3.64203e-08
Marked as misclassified No
Message-id <1295973438.5.0.625022653518.issue10994@psf.upfronthosting.co.za>
In-reply-to
Content
> 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."
History
Date User Action Args
2011-01-25 16:37:18arigosetrecipients: + arigo, brett.cannon, pitrou, docs@python, lukasz.langa, fijall
2011-01-25 16:37:18arigosetmessageid: <1295973438.5.0.625022653518.issue10994@psf.upfronthosting.co.za>
2011-01-25 16:37:16arigolinkissue10994 messages
2011-01-25 16:37:16arigocreate