On 21-jan-05, at 14:07, Bob Ippolito wrote:
On Jan 21, 2005, at 7:44, Jack Jansen wrote:
On 21 Jan 2005, at 08:18, Stuart Bishop wrote:
Just van Rossum wrote:
Skip Montanaro wrote:
Just re.sub("[\r\n]+", "\n", s) and I think you're good to go. I don't think that in general you want to fold multiple empty lines into one. This would be my prefered regex: s = re.sub(r"\r\n?", "\n", s) Catches both DOS and old-style Mac line endings. Alternatively, you can use s.splitlines(): s = "\n".join(s.splitlines()) + "\n" This also makes sure the string ends with a \n, which may or may not be a good thing, depending on your application.
Do people consider this a bug that should be fixed in Python 2.4.1 and Python 2.3.6 (if it ever exists), or is the resposibility for doing this transformation on the application that embeds Python?
It could theoretically break something: a program that uses unix line-endings but embeds \r or \r\n in string data.
But this is rather theoretical, I don't think I'd have a problem with fixing this. The real problem is: who will fix it, because the fix isn't going to be as trivial as the Python code posted here, I'm afraid...
Well, Python already does the right thing in Py_Main, but it does not do the right thing from the other places you can use to run code, surely it can't be that hard to fix if the code is already there?
IIRC the universal newline support is in the file I/O routines, which I
assume aren't used when you execute Python code from a string.
--
Jack Jansen,