Would it make sense to support the context-manager protocol in skyfield.api.load_file()?

[lucabaldini]

I might be missing something fundamental---in which case I apologize in advance---but I just noticed a resource warning in my unit tests
sys:1: ResourceWarning: unclosed file <_io.BufferedReader name='/data/work/ixpe/ixpeobssim/ixpeobssim/instrument/data/de430t_2000_2040.bsp'> make[1]: Leaving directory '/data/work/ixpe/ixpeobssim/tests'
and I realize that I don't have control (I think) on the files open by skyfield.

Would it make sense to implement the context-manager protocol, so that instead of writing
planets = skyfield.api.load_file(ephem_file_path)
I would do
with skyfield.api.load_file(ephem_file_path) as planets: do something
and have the file closed automatically at the exit of the with block?

[brandon-rhodes]

The underlying SPK class does have a close() method, that users requested who were having resource issues. What if we added a close() method to the SpiceKernel that calls the underlying close()? Then users could use modern Python’s ability to context-manage it:

from contextlib import closing

with closing(skyfield.api.load_file(ephem_file_path)) as planets:
    ...

Would that work for your use case? I’m hesitant to add too much code to satisfy a mere testing mechanism, in a case where no actual users have yet reported real problems.

[lucabaldini]

That would be awesome---thanks. And you're right, this is not a real problem by any measure, it's really only a small thing that I noticed testing.

[brandon-rhodes]

Great! Let's leave the issue open til there's a chance to implement it. In the meantime, I think your tests can call planets.spk.close() for now if you simply want to silence the message — or can even do:

from contextlib import closing

planets = skyfield.api.load_file(ephem_file_path)
with closing(planets.spk):
    ...

[lucabaldini]

Now that I think about it, I'd say that, had I found the snippet above in the docs, I wouldn't have opened this issue in the first place. (And I apologize in advance if it's there already and I missed it.)

So maybe adding some direction in the docs is really everything that one needs?

[brandon-rhodes]

It should certainly be mentioned in the docs, yes, and no you didn’t miss it — no one had ever asked, and I had not thought of putting it there myself.

When I get around to adding the docs, I'll see if I also feel inspired to make it more convenient than it currently is :)