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?
-bob
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