Guido van Rossum wrote: > No. Executing a file containing those exact characters produces a > string containing only '\n' and exec/eval is meant to behave the same > way. The string may not have originated from a file, so the universal > newlines behavior of the io module is irrelevant here -- the parser > must implement its own equivalent processing, and it does. I'm still not convinced that this is necessary or desirable behaviour. I can understand the parser doing this as a workaround before we had universal newlines, but now that we do, I'd expect any Python string to already have newlines converted to their canonical representation, and that any CRs it contains are meant to be there. The parser shouldn't need to do newline translation a second time. -- Greg
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