-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
newline defaults for read_csv and write_csv are not consistent #10018
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
this seems like a very particular special case to me. Normally having |
Yeah, it's definitely a rare issue, but I thought it worth documenting in case somebody else runs into it or thinks of a good solution that doesn't impair usability for more typical cases. |
ok, you can add a small note in io.rst / csv section that show the issues w.r.t. '\r' (try to be as general as possible though). |
Wouldn't it be wise for |
I agree, this points to a bug in to_csv. to_csv should quote special characters that occur within fields if to conform with the CSV standard. From RFC4180 documenting the CSV standard (https://tools.ietf.org/html/rfc4180):
|
#10911 reminds me of this. Not sure why this is tagged Docs, as it's a genuine bug in my opinion. |
I ran into this bug today--using python3, to_csv did not put quotes around string with \r in it. |
I ran into this issue today as well. While I was able to resolve the issue by explicitly setting the I agree with others that this is almost certainly a bug in
If I'm interpreting it correctly, carriage returns should definitely be escaped. |
I ran into this bug today as well. We were analyzing online reviews, and many reviews span multiple lines but do not use commas. I support the amendment of |
well a pull request from the community would be a way to resolve this. |
the The issue (as pointed above) is because the A final change would be to not initialize the writer with I'm not sure how this would work in Unix environments where the default line terminator is |
It had to be |
i ran into this issue thanks to https://twitter.com/ComputerBookNew/status/1156186489660665856 containing multiple carriage returns i'm on a linux system w/ pandas 1.5.2
my solution was to switch to parquet and ask myself why i thought csv was ok in the first place |
It's possible to write out a CSV file using the default settings (i.e.,
line_terminator='\n'
inDataFrame.to_csv
) that can't be read back in using the default settings (i.e.,lineterminator=None
).This problem arises when there's a text column that doesn't get quotes around it (e.g., if it has no commas) but has a carriage return.
read_csv
by default thinks that either '\n' or '\r' can be line terminators, so extra rows appear. See example below.It might be best to have the default line terminator for
read_csv
be '\n'. That might reduce usability (e.g., it's nice to be able to load CSVs from UNIX or Windows using the defaults), so maybe it'd be good just to add something to the documentation. Or, maybe a warning could be printed out or exception raised if a CSV file appears to use multiple types of line endings, which shouldn't happen.(IIRC this can also cause the default parsing engine to make python segfault in some cases.)
The text was updated successfully, but these errors were encountered: