> It isn’t responsible for closing files because it doesn’t take files, it takes TextIO. TextIO has a close() method, so this is irrelevant. Rather, the autho

> It isn’t responsible for closing files because it doesn’t take files, it takes TextIO. TextIO has a close() method, so this is irrelevant. Rather, the author of the CSV library made a design decision about whether a CSV reader should take ownership of the underlying IO or not. If it takes ownership, it has the responsibility of closing the file when it's finished. If it doesn't, it doesn't. The decision was made for it not to take ownership. Was this a good decision? Personally, i don't think so. There is nothing useful you can do with an IO object once a CSV reader has used it, so there is no point retaining ownership separately. It just makes more work for the programmer. This is compounded by the fact that there is no way to obtain the underlying IO object from a CSV reader, so you have to hold on to the files separately. In the normal use case where you open a single file and then read from it in a single block of code, this is not a big deal, because you can wrap that in a with block for the file. But as the author points out, it's a serious impediment to using lazy readers. I have also run into this problem when managing multiple open files; i have a tool which opens a bunch of CSV files and merges them in some strange way, and it is sensible to close each file when it is finished, but to do that, i need to hang on to the files, and build some machinery to close the right one at the right time. On the other hand, i can't think of any downsides to deciding, way back when, that CSV readers should close their underlying files. But it's not safe to change that decision now, so we're stuck with it.