pgsql@esiway.net (Marco Colombo) writes:
> No I wasn't sure and I actually was wrong. I've never programmed under
> Windows. I've just learned something.
Indeed, the Windows C runtime translates CRLF to \n on input, and \n
to CRLF on output, for files in "text" mode. Unix programmers tend
not to be aware of the distinction between text and binary modes
(it's actually in standard C) as it makes no difference on Unix. But
it does on Windows (and possibly other platforms).
<offtopic>
Ironically, at the lowest level, Windows behaves just like Unix (files
are pure byte streams) - it's only in the C runtime and application
code that CRLF issues arise, and that's a backward-compatibility hack
dating back to the days of MS-DOS.
</offtopic>
> Apparently, as far as Python is concerned, the platform presents \n
> at C level, so it makes sense for PyRun_SimpleString() to expect \n
> as line terminator. Still I don't understand when the lexxer would
> use \r\n as pysical line ending on Windows, but I can live with it. :-)
Internally, Python uses C string semantics, where \n represents a
newline. Recent versions of Python have "universal newline" support,
which in the broadest sense attempts to be forgiving over line
endings, and treat LF, CRLF, and even bare CR, as line endings. I
don't know exactly where it applies, though, so I believe the most
sensible approach is to always use \n (LF) in strings passed to
Python APIs. This is essentially the "be conservative in what you
send" philosophy.
Paul.
--
A little inaccuracy sometimes saves tons of explanation -- Saki