Terry Reedy wrote: > "Michael Foord" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | Guido van Rossum wrote: > > [snip first part of nice summary of Python i/o model] > > | > The other translation deals with line endings. Upon input, any of > | > \r\n, \r, or \n is translated to a single \n by default (this is nhe > [sic] > | > "universal newlines" algorithm from Python 2.x). This can be tweaked > | > or disabled. Upon output, \n is translated into a platform specific > | > string chosen from \r\n, \r, or \n. This can also be disabled or > | > overridden. Note that \r, when written, is never treated specially; if > | > you want special processing for \r on output, you can write your own > | > translation layer. > > | So the question is, that when a string containing '\r\n' is written to a > | file in text mode on a Windows platform, should it be written with the > | encoded representation of '\r\n' or '\r\r\n'? > > I think Guido pretty clearly said that on output, the default behavior is > that \r is nothing special. If you want a special case exception, write a > special case translator. +1 from me. > > To propose otherwise is to propose that the default semantic meaning of > Python text objects depend on the platform that it might be > output-translated for. I believe the point of universal newline support > was to get away from this. > > | Purity would dictate the latter and practicality the former (IMO)... > > I disagree. Special case exceptions complicate both learnability and code > readability and maintainability. Simplicity is practicality. The symmetry > of 'platform-line-endings =input> \n =output> plaform-line-endings' is both > pure and practical. > > | However, that would mean that round tripping a string would change it > | ('\r\n' would be written as '\r\n' and then read as '\n') > > Whereas \r\r\n would be read back as \r\n, which is what should happen. > Round-trip-ability is practical to me. > > | - on the other > | hand (particularly given that we are treating the data as text and not a > | binary blob) I don't see how writing '\r\r\n' would ever actually be > | useful in text. > > There are two normal ways for internal Python text to have \r\n: > 1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the > same platform). > 2. Intentially put there by a programmer. If s/he also chooses default \n > translation on output, \r<translation of \n> is correct. > Actually, I usually get these strings from Windows UI components. A file containing '\r\n' is read in with '\r\n' being translated to '\n'. New user input is added containing '\r\n' line endings. The file is written out and now contains a mix of '\r\n' and '\r\r\n'.
Michael _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com