CODEWITHSUNDEEP
pythonpypy
Anton
Anton

Reputation: 2341

Cleaning up in pypy

I've been looking for ways to clean up objects in python. I'm currently using pypy.

I found a web page and an example.

First a basic example:

class FooType(object):
    def __init__(self, id):
        self.id = id
        print self.id, 'born'

    def __del__(self):
        print self.id, 'died'


ft = FooType(1)

This SHOULD print:

1 born 1 died

BUT it just prints 1 born

So my question is: how do I clean anything up in PyPy?

Upvotes: 1

Views: 589

Answers (3)

Armin Rigo
Armin Rigo

Reputation: 12990

In your example, __del__ is not called, but that's only because the test program you wrote finishes immediately. PyPy guarantees that __del__ is called some time after the object is not reachable any more, but only as long as the program continues to execute. So if you do ft = FooType(1) in an infinite loop, it will after some time print the died too.

As the other answers explain, CPython doesn't really guarantee anything, but in simple cases (e.g. no reference cycles) it will call __del__ immediately and reliably. Still, the point is that you shouldn't strictly rely on this.

Upvotes: 2

user395760
user395760

Reputation:

The same way you should do it in every other Python implementation, including CPython: By explicitly managing the lifetime in code, rather than by relying on automatic memory management and __del__.

Even in CPython, there's more than one case where __del__ is not called at all, and quite a few cases where it's called much later than you might expect (e.g., any time any object gets caught up in a reference cycle, which can happen quite easily). That means it's essentially useless, except perhaps to debug lifetime issues (but there are memory profilers for that!) and as a last resort if some code neglects cleaning up explicitly.

By being explicit about cleanup, you sidestep all these issues. Have a method that does the cleanup, and make client code call it at the right time. Context managers can make this easier to get right in the face of exceptions, and more readable. It often also allows cleaning up sooner than __del__, even if reference counting "immediately" calls __del__. For example, this:

def parse_file(path):
    f = open(path)
    return parse(f.read()) # file stays open during parsing

is worse than this w.r.t. resource usage:

def parse_file(path):
    with open(path) as f:
        s = f.read()
    # file is closed here
    return parse(s)

I would also argue that such a design is cleaner, because it doesn't confuse the lifetime of the resource wrapper object with the lifetime of the wrapped resource. Sometimes, it can make sense to have that object outlive the resource, or even make it take ownership of a new resource.

Upvotes: 4

Abe Karplus
Abe Karplus

Reputation: 8550

When you need a "cleanup" to run for sure at a specific time, use a context manager.

class FooType(object):
    def __init__(self, id):
        self.id = id
        print 'born'
    def __enter__(self):
        print 'entered'
        return self
    def __exit__(self, *exc):
        print 'exited'

with FooType(1) as ft:
    pass # do something with ft

Upvotes: 4

Related Questions