I understand you are upset but calling the developers names is probably not helping. I agree that either the documentation should note this issue or we should actually try to fix the bug. Having buffered file objects randomly lose data is not a friendly behavior.

Your documentation change is not quite correct, I think. The problem is not that __del__ isn't called, it is that the ordering of the __del__ calls can be unexpected. For this bug, it happens if your buffered file object is part of a garbage reference cycle. The ordering of __del__ calls is essentially random at that point. It can happen that the buffer object gets cleaned up after the file object has been cleaned (closed). In that case, the buffer cannot be written because the file is already closed.

AFAIK, there is no way to fix that in the Python GC logic. We would need to re-structure the _io classes to prevent it (merge the buffer object with the file descriptor object or use a weakref).

I understand you are upset but calling the developers names is probably not helping.

I know, I'm sorry. I'm just tired of this "You should have expected this surprising behavior that is not documented!" victim-blaming. Multiple people told me that the old documentation was correct.

I agree that either the documentation should note this issue or we should actually try to fix the bug. Having buffered file objects randomly lose data is not a friendly behavior.

Thank you for saying that.

Your documentation change is not quite correct, I think. The problem is not that __del__ isn't called, it is that the ordering of the __del__ calls can be unexpected. For this bug, it happens if your buffered file object is part of a garbage reference cycle. The ordering of __del__ calls is essentially random at that point. It can happen that the buffer object gets cleaned up after the file object has been cleaned (closed). In that case, the buffer cannot be written because the file is already closed.

AFAIK, there is no way to fix that in the Python GC logic. We would need to re-structure the _io classes to prevent it (merge the buffer object with the file descriptor object or use a weakref).

Fixing this bug would not prevent data loss, because the docs says that python can exit without calling __del__. The other question is whether

f = open("path")
f.write("data")
del(f)
exit0)

is guaranteed to write to the disk.