Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Close fp if we created it #121

Merged

Conversation

christian-intra2net
Copy link
Contributor

This solves issue #120 ("Clarify who owns fp")

Clarify that fp is owned by whoever created it. Meaning that if an OleFileIO was created/opened with an open file handle as argument, it will never close it. On the other hand, if an OleFileIO was created/opened with a filename, it opens that file internally and therefore takes care to always close the handle.

However, the user of an OleFileIO is responsible for calling close() on it. If she fails to do so a warning is issued to help improve caller code.

Unittests verify that this works as expected and will work in the future. Doc strings also include hints.

This avoids ResourceWarnings caused by unclosed file handles in OleFileIO.

If we opened it, we are responsible for closing it.

This also rids us of ResourceWarnings popping up in newer python versions.

Of course, actually, the creator of an OleFileIO is repsonsible for calling
close() before it goes out of scope. But if the error happens in open()
called from __init__, then caller has no chance to call close().
We got rid of the ResourceWarning now, but sometimes it could be helpful
to teach people proper exception handling...

Just not when open() was called from __init__
Clarify in doc string that fp is owned by caller
Unfortunately, most interesting behaviour cannot be tested automatically
since __del__ can be run at any time and after init failure object is not
assigned
@coveralls
Copy link

Coverage Status

Coverage increased (+0.9%) to 55.176% when pulling 8ee44d8 on christian-intra2net:close-fp-if-we-created-it into eea9b57 on decalage2:master.

@coveralls
Copy link

coveralls commented May 10, 2019

Coverage Status

Coverage increased (+1.8%) to 56.125% when pulling 0e34cee on christian-intra2net:close-fp-if-we-created-it into eea9b57 on decalage2:master.

@christian-intra2net
Copy link
Contributor Author

Tried to implement tests for issuing the warning, but del really cannot be predicted and not realiably controlled using module gc nor a forked interpreter session (e.g. not called at session end in py2.7)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants