Home Original page

os.linesep under Windows

Fred L. Drake, Jr. fdrake at acm.org
Tue May 30 17:21:34 EDT 2000 
andres at corrada.com writes:
 >  This one has bitten me in the past, but on a Mac. Am I correct in saying
 > that the way sys.write( os.linesep ) works on the Windows platform is:

  The C stdio functions convert '\n' to the underlying operating
system's line separator; that's what their supposed to do.  (The stdio
functions are the ones that operate on FILE* values, not file
descriptors.)  So '\n' converts to '\x0D\x0A' ('\r\n') in the C
libraries, and that's what appears in the file.  The '\x0D\x0A' is
converted back to '\n' when read back in.
  Note that these conversions are not performed if the file is opened
in binary mode; open(..., 'wb') does not enable this conversion.
  This doesn't actually have much to do with Python, but rather with
the underlying libraries.

 > Fred, out of curiosity, what applications need to worry about os.linesep
 > and/or what are those few cases where it should be used directly?

  I think sockets are always opened in binary mode, so this could be
useful when sending data over a socket, but it assumes that the other
end uses the same line separator as the local host (a bad
assumption!).  The most reasonable use is when converting text that
uses any line separator (or a mix) to the local separator, but that's
a stretch.  I'm not sure what the specific situation was that called
for the addition of os.linesep.  Perhaps someone needed to be able to
predict the value that would be returned from <file>.tell() after
writing a line separator?  That sounds a little bogus, but only a
little.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
More information about the Python-list mailing list