On 8/14/2013 1:05 PM, random...@fastmail.us wrote:
On Wed, Aug 14, 2013, at 10:32, wxjmfa...@gmail.com wrote:
I'm always and still be suprised by the number of hard coded
'\n' one can find in Python code when the portable (here
win)
os.linesep
'\r\n'
exists.
Because high-level code isn't supposed to use the os module directly.
This is a bit extreme, but definitely true for os.linesep and *much* of
os other than os.path and maybe os.environ.
Text-mode streams automatically convert newlines you write to them.
By default, <any possible linesep> to \n when reading files;, \n to
os.linesep when writing. Windows is the only major OS for which
os.linesep is not \n.
The full details, from the builtin 'open' entry:
"
newline controls how universal newlines mode works (it only applies to
text mode). It can be None, '', '\n', '\r', and '\r\n'. It works as follows:
When reading input from the stream, if newline is None, universal
newlines mode is enabled. Lines in the input can end in '\n', '\r', or
'\r\n', and these are translated into '\n' before being returned to the
caller. If it is '', universal newlines mode is enabled, but line
endings are returned to the caller untranslated. If it has any of the
other legal values, input lines are only terminated by the given string,
and the line ending is returned to the caller untranslated.
When writing output to the stream, if newline is None, any '\n'
characters written are translated to the system default line separator,
os.linesep. If newline is '' or '\n', no translation takes place. If
newline is any of the other legal values, any '\n' characters written
are translated to the given string.
"
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
