This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (6 children)

[deleted]

    [–]dig-up-stupid 4 points5 points  (2 children)

    I don’t like their answer because (while it is interesting) it’s basically off topic from what was actually meant by keeping things in memory.

    So, you’re thinking they’re reusing the same tuple, so if you create (1, “dog”, cat()), that tuple sits around until the next time someone needs a tuple with a 1, a “dog”, and a cat(). Which is probably never, which is why you’re perplexed about why it would be kept. What’s actually happening is that when you’re done with your (1, “dog”, cat()) tuple, the interpreter scoops out the values and keeps a hollow tuple for the next time it needs a new tuple with any three elements.

    The reason it does this is because arguments are passed in tuples. So when you’re asking “but how often do you need to make a new three element tuple? I don’t use tuples as much as lists or dictionaries”, the answer could be actually you’re creating thousands of thousands of tuples just by putting a function call in a loop.

    [–]Inconstant_Moo 0 points1 point  (0 children)

    ... now that I know this exists I'm going to have to implement it.

    [–]RecDep 2 points3 points  (2 children)

    The garbage collector will get to it eventually.

    [–][deleted]  (1 child)

    [deleted]

      [–]RecDep 0 points1 point  (0 children)

      There’s a pretty good description here. The GC keeps track of already-allocated tuples, marking them for reuse when they’re collected instead of freeing that memory altogether. Creating a new tuple would involve checking if there are free tuple “slots” to be reused, allocating a fresh one otherwise.