3 ms·
Except that it can. I hardly ever use something other than stdlib’s csv. It’s a perfectly good csv parser for production use.
by drej 6y ago
Except that it can. I hardly ever use something other than stdlib’s csv. It’s a perfectly good csv parser for production use.
- cbkeller 6y agoDoesn't that validate the applicability of the benchmark then? GP said: > A typical user will rarely ever use the built in CSV library in Python as a criticism of the benchmark, but if a typical user does use stdlib’s csv after all, then it seems like your disagreement is perhaps with GP and not with Stefan.
- mlthoughts2018 6y agoNo you’re mixing up two things. 1. Python’s std csv parser is very fast & versatile, perfectly good for a range of use cases that don’t have unusual needs. 2. For any production use cases whose needs aren’t met by the std csv parser, nobody would use it and nobody has to - plenty of other options exist (rightfully) as separate packages that allow the user to choose a different point of trade-off properties if they don’t like the std module’s defaults. Nothing says the std isn’t good enough for production - it is. Just most people will use something application-specific and they have tons of options.
- giantrobot 6y agoIt does validate the benchmark but that doesn't make the benchmark particularly useful. In both Python and Julia if loading your data from CSV is a bottleneck you'll do something else. If it's not a bottleneck it doesn't matter. If you've got a Python code base it would cost far more in terms of effort and dollars to convert it all to Julia than to just find a better way to load data. If you've got a green field project and CSV reading is a big portion of the task load then it makes sense to pick Julia I guess.