Michael Foord <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > Michael> Actually, I usually get these strings from Windows UI > > Michael> components. A file containing '\r\n' is read in with '\r\n' > > Michael> being translated to '\n'. New user input is added containing > > Michael> '\r\n' line endings. The file is written out and now contains a > > Michael> mix of '\r\n' and '\r\r\n'. > > > > So you need a translation layer between the UI component and your code. > > Treat the component as a text file and perform the desired mapping. Yes? > > Actually the problem was reported by one of the IronPython developers on > behalf of another user. We stick to using the .NET file I/O and so don't > have a problem. The only time it is an issue for us is our tests, where > we have string literals in our test code (where new lines are obviously > '\n') and we do a manual 'replace'. Not very difficult. > > It is just slightly ironic that the time Python 'gets it wrong' (for > some value of wrong) is when you are using text mode for I/O :-)
Plus ca change, .... That has been the problem for as long as I have been using the byte stream model (nearly 40 years now). Provided that you can get control, OR there are well-defined semantics, you can sort things out. The semantics "we define only the trivial case, and the programmer must do something arcane, undefined and system-dependent for the rest" means that it is impossible for an interface to do the 'right' translation unless it knows what each side of it is assuming. As I say, there are solutions. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761 Fax: +44 1223 334679 _______________________________________________ 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