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, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4