[Python-Dev] [python] Re: New lines, carriage returns, and Windows (original) (raw)

Paul Moore p.f.moore at gmail.com
Sat Sep 29 21:47:35 CEST 2007

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. ;-)

Given the current lengthy discussion about newline translation, maybe it isn't such a great thing :-)

Seriously, you do need a wrapper in this particular case - to convert the .NET line ending convention to Python's. The issue here is that such a wrapper is so trivial, that it's usually easier to simply do the translation with adhoc .replace('\r\n', '\n') calls. The problem comes when you accidentally forget a translation - then you get the clash between the .NET (\r\n) and Python (\n) models. But of course, the solution in that case is to simply add the omitted translation, not to change Python's IO model.

Of course, all this grand theory is just that - theory. In my case, it helped me understand what's going on, but that's all. For real life code, you just add the appropriate replace() calls. Whether theory helps you keep track of where replace() is needed, or whether you just know, doesn't really matter much.

But regardless - the Python IO model doesn't need changing. (Not even 2.x, and the py3k model is even better in this regard).

Paul.

More information about the Python-Dev mailing list