mirror of https://github.com/python/cpython.git
Redo the comment about the 2.5 change in quoted-newline handling.
This commit is contained in:
parent
6458452c8a
commit
10183b8e40
|
@ -72,13 +72,15 @@ All data read are returned as strings. No automatic data type
|
||||||
conversion is performed.
|
conversion is performed.
|
||||||
|
|
||||||
\versionchanged[
|
\versionchanged[
|
||||||
If literal newlines are important within a field, users need to read their
|
The parser is now stricter with respect to multi-line quoted
|
||||||
file in a way that preserves the newlines. The behavior before 2.5 would
|
fields. Previously, if a line ended within a quoted field without a
|
||||||
introduce spurious characters into quoted fields, with no way for the user
|
terminating newline character, a newline would be inserted into the
|
||||||
to control that behavior. The previous behavior caused considerable
|
returned field. This behaviour caused problems when reading files
|
||||||
problems, particularly on platforms that did not use the \UNIX{} line ending
|
that embed carriage-return characters within fields, so in 2.5 the
|
||||||
conventions, or with files that originated on those platforms --- users were
|
behaviour was changed to return the field without inserting newlines. As
|
||||||
finding mysterious newlines where they didn't expect them]{2.5}
|
a consequence, if newlines embedded within fields are important, the
|
||||||
|
input should be split into lines in a manner which preserves the newline
|
||||||
|
characters.]{2.5}
|
||||||
|
|
||||||
\end{funcdesc}
|
\end{funcdesc}
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue