[Python-Dev] End of the line

Tim Peters tim_one@email.msn.com
Thu, 22 Jul 1999 23:08:07 -0400


[Tim]
> The latest versions of the Icon language ... normalizes Unix, Mac
> and Windows line endings to plain \n.  Writing in text mode still
> produces what's natural for the platform.

[/F]
> if we were to change this, how would you
> tell Python to open a file in text mode?

Meaning whatever it is the platform libc does?

In Icon or REBOL, you don't.  Icon is more interesting because they changed
the semantics of their "t" (for "translated") mode without providing any way
to go back to the old behavior (REBOL did this too, but didn't have Icon's
15 years of history to wrestle with).  Curiously (I doubt Griswold *cared*
about this!), the resulting behavior still conforms to ANSI C, because that
std promises little about text mode semantics in the presence of
non-printable characters.

Nothing of mine would miss C's raw text mode (lack of) semantics, so I don't
care.

I *would* like Python to define portable semantics for the mode strings it
accepts in the builtin open regardless, and push platform-specific silliness
(including raw C text mode, if someone really wants that; or MS's "c" mode,
etc) into a new os.fopen function.  Push random C crap into expert modules,
where it won't baffle my sister <0.7 wink>.

I expect Python should still open non-binary files in the platform's text
mode, though, to minimize surprises for C extensions mucking with the
underlying stream object (Icon/REBOL don't have this problem, although Icon
opens the file in native libc text mode anyway).

next-step:-define-tabs-to-mean-8-characters-and-drop-unicode-in-
    favor-of-7-bit-ascii<wink>-ly y'rs  - tim