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 loewis
Recipients benjamin.peterson, hynek, loewis, pitrou, serhiy.storchaka, stutzbach
Date 2012-07-30.09:01:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
>> For the PyAccu, AFAICT, objects cannot leak out of it (except for  
>> gc.getobjects in debug mode).
> Not only in debug mode.

I see. I meant sys.getobjects, which is in debug mode only, but
I now see that gc.get_objects will get the list (but not the strings)
of the Accu.

That still leaves readnl and writenl.

> I think the standard library should provide a method for recursive  
> calculation of memory (in some sense, perhaps using different  
> strategies), but that should wait up to 3.4.

Actually, this is (and should be) a separate project:

> __sizeof__ should count non-object memory that is not available for  
> GC. As I understand it.

I think you misunderstand slightly; the GC relevance is only a side
effect. __sizeof__ should only account for memory that isn't separately
accessible. The notion of "separately accessible" is somewhat weak, since
it may depend on the container.

Non-PyObject blocks clearly need to be accounted for.

PyObject blocks normally don't need to be accounted for, as they are typically
accessible separately, by the following means:
- gc.get_objects (for GC objects)
- gc.get_referents (for contained non-GC objects)

There are also irregular ways to get objects:
- in debug mode only: sys.getobjects
- customer access functions or attributes

For memory accounting, it would really be best if the latter two categories
wouldn't exist, i.e. if all non-GC objects were still visible through  
Date User Action Args
2012-07-30 09:01:18loewissetrecipients: + loewis, pitrou, benjamin.peterson, stutzbach, hynek, serhiy.storchaka
2012-07-30 09:01:17loewislinkissue15490 messages
2012-07-30 09:01:17loewiscreate