On 1/6/06, Cliff Wells <[EMAIL PROTECTED]> wrote: > Actually I've seen the same thing and never had an explanation for it. > I found myself having to run unix2dos on a file with fragments > copy/pasted from the web (getting a "syntax error" on blank lines, for > instance). I don't think this should happen, although the idea of an > actual bug in Python is a bit startling to me. AFAIK, Python is > supposed to handle newline translation transparently and I'm not aware > that eval() is an exception to that (although it seems possible that the > type of translation happening is global, at least within the scope of > the current module and that fragments of code within that module must be > of the same line-ending type... but that's just speculation).
If a text file is going to be evaluated/compiled by Python, the file should be opened with mode 'rU' and not just 'r'. The 'U' turns on the universal newline translation. eval expects input with only \n newlines for line endings. If it encounters a \r (as a result of reading a file in "binary" mode on Windows, or reading a Windows-created file on a non-Windows system) it will get confused. So in summary, one place you'll get the universal newline support you want is by appending 'U' to the mode of a call to file(). :) -- Matthew R. Scott
