4 ms·
That's being a little pedantic IMO. From a practical, user-facing perspective, the CSV library Reader takes in files. And they know this, which is why the docum
by solidasparagus 6y ago
That's being a little pedantic IMO. From a practical, user-facing perspective, the CSV library Reader takes in files. And they know this, which is why the documentation specifically calls out gotchas related to passing in a file object and the example code shows how it should work with a file object [1].
[1] https://docs.python.org/3/library/csv.html#csv.reader https://docs.python.org/3/library/csv.html#csv.reader
- kevin_thibedeau 6y agoFile like objects are not necessarily files. A library consuming them can't presume to manage them.
- throwaway894345 6y agoIt’s not pedantic. It’s a very important distinction for exactly this use case. The CSV library doesn’t and shouldn’t close the source object because it may not have a close method and even if it does, someone else might be planning on closing it later (the scope that owns it) which might be an error depending on the implementation of the source’s close() method. Only the resource owner should close it, and the CSV library shouldn’t be the owner.
- anang 6y agoI don’t think it’s at all pedantic, the library doesn’t accept a path and by extension is one step of abstraction away from a file. I’ve used the CSV library many times with an in memory TextIO object (like an http response). It’s an important distinction.