Coverage decreased (-0.7%) to 93.116% when pulling 144891b on ankostis:leaks2 into 6e55a1c on gitpython-developers:master.

Coverage decreased (-0.7%) to 93.116% when pulling 144891b on ankostis:leaks2 into 6e55a1c on gitpython-developers:master.

@Byron can you check these lines where a memoryview is crated?

It took me the half month to realize that this is leaking badly, and I want you to check the history of this commits leading up to it, because I cannot understand whether they were mistake or intentional, and what would be the repercussions (ie, performance?).

@ankostis Sorry for the very late reply. I am no holiday now, and am working through everything that piled up.
About the matter: I don't understand why this would leak in the first place. Does that mean it's a python 3 only issue? Also I wonder how anything can leak in the first place unless there are dependency cycles.
The comment in the respective are of the code also contains an alternative. It appears that it was chosen just for performance reasons. Maybe alternatives do by now exist too.

Yes, it is a python-3 issue, because the destructors are not deterministic.
Untill all memoryview for some mmemp have close, neither the memmap nor its file can be collected.

Now, in python3, you can slice memmaps as if they were memoryview, so they are not strictly needed, unless it is a performance issue. From some quick experiments I had done, I could not see any benefits, quite the contrary, but it's been a long time and I don't remember exactly.

If using direct access would be a solution, then it probably should be used instead. Correctness over performance I would say.
The main driver behind using the 'buffer' interface was to prevent copying of the slices that are read, and thus maintain the awesome properties of a memory map even in python. I do remember me digging around in python source code to see if copies were made.
However, now is a different time, and slicing memory maps directly in python 3 sounds appealing to me.