John J. Lee <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Alex Martelli) writes: > [...] > > If you're trying to test your code to ensure it explicitly closes all > > files, you could (from within your tests) rebind built-ins 'file' and > > 'open' to be a class wrapping the real thing, and adding a flag to > > remember if the file is open; at __del__ time it would warn if the file > > had not been explicitly closed. E.g. (untested code): > [...] > > In general __del__ methods interfere with garbage collection, don't
Yes, cyclic gc only. > they? I guess in the case of file objects this is unlikely to be > problematic (because unlikely to be any reference cycles), but I > thought it might be worth warning people that in general this > debugging strategy might get rather confusing since the __del__ could > actually change the operation of the program by preventing garbage > collection of the objects whose lifetime you're trying to > investigate... Yeah, but you'll find them all listed in gc.garbage for your perusal -- they DO get collected, but they get put in gc.garbage rather than FREED, that's all. E.g.: >>> class a(object): ... def __del__(self): print 'del', self.__class__.__name__ ... >>> class b(a): pass ... >>> x=a(); y=b(); x.y=y; y.x=x >>> del x, y >>> gc.collect() 4 >>> gc.garbage [<__main__.a object at 0x64cf0>, <__main__.b object at 0x58510>] So, no big deal -- run a gc.collect() and parse through gc.garbage for any instances of your "wrapper of file" class, and you'll find ones that were forgotten as part of a cyclic garbage loop and you can check whether they were explicitly closed or not. Alex -- http://mail.python.org/mailman/listinfo/python-list
