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

[Jack Jansen]

Recently, Guido van Rossum <guido@python.org> said:
> I think the presence or absence of the 'b' option on file open modes
> should be interpreted by Python; the stdio files are always opened in
> 'b' mode.

Yes, you're right, I forgot about that one. This isn't really needed
on the Mac (where \n and \r are simply reversed) but it is needed on
windows, which would do unknown things to a lone \r or \n.

> What do you plan to do about the seek offset [...]

No problem: fseek returns a magic cookie by definition so we can just
use the underlying fseek/ftell.

> [...] and interactive input?

Ouch:-(

> (I think I saw a proposal for a flag "skip following \n" which makes
> sense to me.)

Yes, but so far my thinking has been a stateless implementation, and
this flag would be to be in some per-FILE*-state. Now we can get that
easily in the Python infrastructure, by creating a dictionary that
maps FILE* addresses to our state structures, but it'll make the calls
quite a bit more expensive.

Hmm: maybe the problem isn't all that serious anyway: the only place
where we can find unadorned \r as lineterminator on interactive input
is the MacPython console, really. And we know exactly where that is
(fileno()==1 and platform==MacPython). So we can define away the
problem with one extra rule: \r isn't allowed as interactive
lineending with the exception of MacPython. (Python run from the unix
commandline on OSX will see normal \n).
--
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