Ensure file resources are released#326
Merged
+17 −17
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Byron added a commit that referenced this pull request Jul 27, 2015
…patch-1 Ensure file resources are released
Member
Byron commented Jul 27, 2015
Thank you very much ! I am afraid there are many more issues of that kind buried in the code as I was wrongly assuming (back in the days) that an object destructor is deterministically called (such as in C++). This led to me failing to explicitly close files. |
Author
vokimon commented Jul 27, 2015
what about starting with a grep for 'open'? |
Member
Byron commented Jul 27, 2015
One will have to spread these efforts among GitDB and SMMap as well. Both should have mechanisms to release resources, but I doubt this works properly. For now the best way to workaround these resource related issues is to use a |
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull request Nov 3, 2023
This removes a comment noting that a try-finally block had been present (or had been intended), but was removed because some version of Python had imposed a limitation on yield appearing in try-finally. That comment was obsolete as of 58c5b99 (gitpython-developers#326), which wrapped the relevant code in a with-statement, because: 1. Since then, the cleanup is done in a manner equivaent to try-finally. 2. It turned out, as noted in that PR, that cleanup had not always been done automatically. (This was contrary to the prediction given in the comment.) 3. At some point before that, the limitation that had prevented the use of try-finally no longer affected any supported version of Python. Specifically, it appears the only limitation that this could be was the limitation lifted in Python 2.5, where along with the addition of the close() method which causes try-finally to be called (and is itself called when a generator object is finalized), yield in a try-block with an associated finally-block became permitted, since the call to close() was sufficient to run the finally-block (by raising GeneratorExit). For details, see: https://docs.python.org/3/whatsnew/2.5.html#pep-342-new-generator-features (This obsolete comment was one of the things I discovered while working on gitpython-developers#1725, but I didn't include this change there, having not yet looked into the history of the code enough to be sure.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull request Nov 3, 2023
This removes a comment noting that a try-finally block had been present (or had been intended), but was removed because some version of Python had imposed a limitation on yield appearing in try-finally. That comment was obsolete as of 58c5b99 (gitpython-developers#326), which wrapped the relevant code in a with-statement, because: 1. Since then, the cleanup is done in a manner equivaent to try-finally. 2. It turned out, as noted in that PR, that cleanup had not always been done automatically. (This was contrary to the prediction given in the comment.) 3. At some point before that, the limitation that had prevented the use of try-finally no longer affected any supported version of Python. Specifically, it appears the only limitation that this could be was the limitation lifted in Python 2.5, where along with the introduction of close(), which is automatically called when a generator object is finalized, it became permitted for yield to appear in a try-block with an associated finally-block, on the grounds that calling close() runs the finally-block (by raising GeneratorExit). For details, see: https://docs.python.org/3/whatsnew/2.5.html#pep-342-new-generator-features (This obsolete comment was one of the things I discovered while working on gitpython-developers#1725, but I didn't include this change there, having not yet looked into the history of the code enough to be sure.)
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SymbolicReference leaked file descriptor resources when iterating on refs. unittest module complained:
symbolic.py:153: ResourceWarning: unclosed file <_io.TextIOWrapper name='...../gitrepo/.git/packed-refs' mode='rt' encoding='UTF-8'>
symbolic.py:148: ResourceWarning: unclosed file <_io.TextIOWrapper name='....../gitrepo/.git/packed-refs' mode='rt' encoding='UTF-8'>