[Python-Dev] [python] Re: New lines, carriage returns, and Windows

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