[EMAIL PROTECTED] (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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org