[Biopython-dev] Tests on x64 Win 7

Peter Cock p.j.a.cock at googlemail.com
Mon Apr 28 19:49:16 UTC 2014


On Mon, Apr 28, 2014 at 8:07 PM, Manlio Calvi <manlio.calvi at gmail.com> wrote:
> Hi people,
>
> I rebuild and retest the last biopython commit, no test failed so I
> here signal some recurrent warning in python3.4, nothing too bad but
> there is a lot of file left not closed. This problem could be related
> to the one with the remaing files after the tests? Seems to me was the
> same files.
> If that the case it could be a class who open and don't the files
> after the read.

The problem is lots of (old) Python code tends to do something
like this:

handle = open(filename)
handle.read() etc
#handle.close() missing

This relies on C Python doing garbage collection when the
handle variable goes out of scope, which will close the handle.
This is not so predictable on alternative Python implementations
like Jython and PyPy so the handle may not get closed for
some time. That can cause problems, for example the OS
imposes limits on the number of open files, and Windows will
refuse to delete a file if there are handles open to it.

The solution is to either close the handle explicitly, or use
a context manager (with statement).

Now in some senses the warning is harmless, see:
http://emptysqua.re/blog/against-resourcewarnings-in-python-3/

By default the ResourceWarning is silent, but it seems
something sometimes goes wrong with our test framework
and this starts to show up (due to a possible design flaw,
the Python warnings filters are global):
http://lists.open-bio.org/pipermail/biopython-dev/2013-April/010521.html

How we test for warnings and/or silence them is something
in need of an overhaul - perhaps the warnings.catch_warnings
context manager would help (new in Python 2.6, so we
can use that)?

> PS after this mail I'll send another mail with the logs. Please Peter,
> acknowledge that mail (and the one before that on Pypy subject).

I approved those emails with attachments which were
waiting for moderation.

Peter



More information about the Biopython-dev mailing list