> The csv version returns an iterator over a closed file. It's a violation of procedural abstraction to know whether the result of load is lazily evaluated or n

> The csv version returns an iterator over a closed file. It's a violation of procedural abstraction to know whether the result of load is lazily evaluated or not; it's just supposed to implement an interface. Moreover, according to this best practice, it's impossible to write the csv version correctly. As absurd as it sounds, it's just an abstraction that can't exist. This is simply not true. A load being lazy or not will often be a part of API documentation. In some cases, documentation will include that a .close() needs to be manually called. It's also trivial to read an entire CSV file, close it, and return an array of lines, or a dataframe, or whatever. Of course, you probably don't need to do it with a generator, and it won't be a two-liner (although @Izkata gives a two-liner example). In that implementation, you'd achieve behavior parity with json.loads(...). > No, it will not be fixed. This version only appears to work by not closing the file until the generator is exhausted or collected. I'm no fan of Python (even though I use it every day), but this is extremely well documented in PEP 342[1]. I'm honestly not sure what the complaint is here. I guess the standard Python CSV library is a bit wonky, but that's about it. [1] https://legacy.python.org/dev/peps/pep-0342/ https://legacy.python.org/dev/peps/pep-0342/