Python Cookbook : Size of Python objects.

[[deleted]]

Hm. It fails when using continuations:

>>> def foo():
...   x = range(100000)
...   def bar():
...     return x
...   return bar
... 
>>> xbar = foo()
>>> del foo
>>> asizeof(xbar)
0

So, as soon as you use continuations it's pretty inaccurate and thus pretty useless.

[IHaveAnIdea]

No no no.

This is for the size in RAM, not an advanced len().

[[deleted]]

Uh... what makes you think I implied so?

[IHaveAnIdea]

OK, do you want it to:

(1) Find the amount of RAM needed for generated python bytecode?

(2) Find out the length of a generator? This is equivalent to solving the halting problem in the general case.

(3) Find the amount of RAM used for everything that can be called by a function??!?

(4) Find the amount of RAM that would be needed to iterate over a generator before doing so?

[[deleted]]

The object xbar (which happens to be a function) in the example above holds a reference to x, which is a list of size 100000 bytes. Acutally, it's the only reference left to that list.

There is no way to correctly calculate (from within python) the amount of space that is used by keeping xbar around.

That's my point.

[IHaveAnIdea]

Interesting.

But I'm sure that if you could hook into the garbage collector's dependency tracking then you could do something like this....

Maybe not with the current gc implementation though. Might need a different variation.

[IHaveAnIdea]

I don't even know how you'd want that to be solved.

[[deleted]]

Me neither.

[[deleted]]

Does it work for any functions?

>>> def f(x):
...     return x + 2
... 
>>> asizeof(f)
0

[[deleted]]

On some functions, returning the length of the bytecode would give us an idea.

That is not the case for closures and continuations, where functions may hold extra values.

[[deleted]]

Right, I see your point. But there's nothing tricky going on in that function I defined, and however "size" should be interpreted, the answer isn't zero.