[Pythonmac-SIG] Re: MacPython and line-endings

[Jack Jansen]

Recently, Paul Miller <paul@fxtech.com> said:
> Please forgive my ignorance:

Forgiven:-)

> Why can't we just replace the fgets call that reads the next line for 
> script parsing with a function that does a buffered char-by-char read until 
> any combination of \r, \n, or \n\r is found? Pretty much all cross-platform 
> text-file reading code does it this way. The goal is to find a 
> line-terminator - do we *really* care what it is?

Well, this is part of the problem. We also want to give a consistent
picture to the world. So if the parser understands newlines when you
do "import foo", you should also see newlines if your python script
does open("foo.py"). Moreover, this should work not only for
fp.readline() but also for fp.read().

And things are again made more difficult by interactive input: in a
file you can easily look ahead whether a \r is followd by a \n (so
it's a DOS linefeed) but for interactive files you don't want to do
this, because if you're on a Mac and \r is end-of-line your attempt to
read ahead to check whether the next char is a \n and you have a DOS
linefeed and seek back will mean the program won't continue until
the user has typed the first char on the next line...

As usual in programming this seems to be easy to solve for 80% of the
cases but the remaining 20% is important too...
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm