Steve Holden wrote:
Michael Foord wrote:
Steven Bethard wrote:
On 9/29/07, Michael Foord
wrote: Terry Reedy wrote:
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
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'.
Out of curiosity, why don't the Python wrappers for your Windows UI components do the appropriate '\r\n' -> '\n' conversions?
One of the great things about IronPython is that you don't *need* any wrappers - you access .NET objects natively (which in fact wrap the lower level win32 API) - and the .NET APIs are usually not as bad as you probably assume. ;-)
This thread might represent an argument that you *do* need wrappers ...
You just have to be aware that line endings are '\r\n'. I'm not sure how or if pywin32 handles this.
Presumably that awareness should be implemented by the "unnecessary" wrappers.
Well, it's an OS level difference and I thought that in general Python *doesn't* try to protect you from OS differences. These different line endings are returned by the components - and making the string type aware of where it comes from and transform itself accordingly seems odd. It also leaves you with all sorts of other problems like string comparison (do you ignore difference in line endings?), string length (on different sides of the .NET / IronPython strings would report different lengths). It is also different from how libraries like wxPython behave - where they *don't* protect you from OS differences and if a textbox has '\r\n' line endings - that is what you get... Michael http://www.manning.com/foord
regards Steve