[Biopython-dev] Debugging the warning filters in the unit tests

[Peter Cock]

On Wed, Apr 10, 2013 at 5:30 PM, Wibowo Arindrarto
<w.arindrarto at gmail.com> wrote:
> Hi Peter,
>
> Could we apply a simple warning filter prior to the doctest run? Something
> like:
>
> with warnings.catch_warnings():
>     warnings.simplefilter('ignore', ResourceWarning)
>     suite.run(result)
>

The ResourceWarning is already silenced by default, unless running
Python in debug mode. The issue is something is resetting the
warning filters - most likely one of our unit tests doing something
slightly wrong with warning filters.

> However, maybe a related issue is whether we want to silence this
> warnings at all?

True, there is something to be said for deliberately showing any
ResourceWarning messages from our test suite.

> After digging a bit into the tests and code, the warnings do seem to be
> generated by real leaky handles (so not a Python bug). For example, the
> SearchIO and SeqIO warnings here:
> http://testing.open-bio.org/biopython/builders/Linux%2064%20-%20Python%203.3/builds/140/steps/shell/logs/stdio
> seems to be caused by the `index` or `index_db` function not closing its
> open file handles. When the doctest suite resets the global environment for
> each test (doctest.py:L1439), Python discovers that these handles are still
> open and raises a warning.

The dictionary objects from SeqIO/SearchIO do have close methods.
The SQLite backend had this for a while, I only added this to the in
memory dictionary to close the sequence file handle this week:
https://github.com/biopython/biopython/commit/5822f83444d9ccf028bb32b5978208594b4d9c07

The SQLite handles had to be closed in order for the test suite
to delete the index files after usage - which is why I added that
close method much earlier.

So was can now explicitly close those handles in the doctests,
with the downside of making the example a little more complex.

> I haven't checked if the same issue is the root cause of other
> ResourceWarning occurences. Perhaps we need to look deeper
> into this?

One common bad pattern was unit test code which did things
like this,

data = open(filenname).read()

rather than:

with open(filename) as handle:
    data = handle.read()

or on pre-Python 2.5:

handle = open(filename)
data = handle.read()
handle.close()

The one line version is still very widely used but only safe on
C Python where the garbage collection is predictable and will
close the handle when it goes out of scope.

Peter