Yeah, it was just a simple example. Although using just pandas (without something like dask) for loading terabytes of data at once into a single dataframe may not be the best idea, even with enough memory.

I think portability and easy parsing is the only advantage od CSV. It's definitely good enough (maybe even the best) for small datasets but if you have a lot of data you need a compressed binary format, something like parquet.

But which separator is it, and which line ending? ASCII, UTF-8, UTF-16 or something else? What about quoting separators and line endings? Yes, there is an RFC, but a million programs were made before the RFC and won't change their ways now.

Also you can gzip CSV and still stream them.

Have you heard that there are great serialised file formats like .parquet from appache arrow, that can easily be used in typical data science packages like duckdb or polars. Perhaps it even works with pandas (although do not know it that well. I avoid pandas as much as possible as someone who comes from the R tidyverse and try to use polars more when I work in python, because it often feels more intuitive to work with for me.)

If you have a csv bigger than like 500mb you need more than 8gb of ram to open it

Wait till you hear about WSV

Pandas supports lazy loading and can read files in chunks. Hell, even regular ole Python doesn't need to read the whole file at once with csv

Oh, I know, believe me. I have some painful first-hand experience with such code.

CSV is not optimal, but then someone shows up and gives you 60GB of JSON instead of 600MB of CSV.

Fine! .csv.gz ftw!

I mean, yeah, that's the point of compression. I don't quite get what you mean by that comment.