[Pythonmac-SIG] \r in string causes eval to fail

[Kevin Altis]

On Sep 10, 2004, at 11:41 AM, Bob Ippolito wrote:

>
> On Sep 10, 2004, at 2:25 PM, Kevin Altis wrote:
>
>> I've run into a problem with eval on the Mac and I'm not sure whether 
>> it is a bug or expected behavior. The problem is that if \r is used 
>> as the line terminator instead of \n then it causes eval to fail. I 
>> ran into this while copying and pasting some text to eval and the 
>> clipboard had converted my newlines to returns. Here is an example 
>> done in the shell. As you can see below, using newlines as a 
>> separator is fine, but return (\r) isn't. This would probably only 
>> come up on the Mac where return (CR, \r) is the default line 
>> terminator, but I didn't know whether universal newlines support was 
>> supposed to deal with this kind of issue.
>>
>> >>> s = """{'type':'Button',\r'name':'Button1',\r'position':(10, 
>> 10),\r'label':'Button1',\r}"""
>> >>> s2 = s.replace('\r', '\n')
>> >>> eval(s2)
>
> "Universal newlines" is only a mode for the file object (as far as I 
> know anyway).  eval and compile take strings.
>
> It would be a lot more portable to do this to normalize your input 
> strings:
>
> '\n'.join(s.splitlines())
>
> splitlines is essentially universal newlines support at the string 
> level.  It might be smart to do this internally, maybe this deserves a 
> feature request or bug report?
>
I double-checked and eval doesn't like \r\n line endings either as you 
would get on Windows, so the behavior is consistent. It might be a good 
idea to have line endings dealt with automatically with compile, eval, 
exec, etc. but this would need to be brought up on python-dev. My guess 
is that there are a lot of places in the language and standard libs 
where the input arg is supposed to be a string using linefeeds as the 
line terminator, so it would be difficult to find and handle all the 
cases.

ka