mirror of https://github.com/python/cpython
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.
|
||||
|
||||
\versionchanged[
|
||||
If literal newlines are important within a field, users need to read their
|
||||
file in a way that preserves the newlines. The behavior before 2.5 would
|
||||
introduce spurious characters into quoted fields, with no way for the user
|
||||
to control that behavior. The previous behavior caused considerable
|
||||
problems, particularly on platforms that did not use the \UNIX{} line ending
|
||||
conventions, or with files that originated on those platforms --- users were
|
||||
finding mysterious newlines where they didn't expect them]{2.5}
|
||||
The parser is now stricter with respect to multi-line quoted
|
||||
fields. Previously, if a line ended within a quoted field without a
|
||||
terminating newline character, a newline would be inserted into the
|
||||
returned field. This behaviour caused problems when reading files
|
||||
that embed carriage-return characters within fields, so in 2.5 the
|
||||
behaviour was changed to return the field without inserting newlines. As
|
||||
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}
|
||||
|
||||
|
|
Loading…
Reference in New Issue