[Python-Dev] RE: Python on Windows chapter.

[Tim Peters]

[Mark]
>> ... The case for abandoning the CRTL's text mode gets stronger
>> and stronger!

[Gordon]
> If you're tying this in with Tim's Icon worship,

Icon inherits stdio behavior-- for the most part --too.  It does define its
own mode string characters, though (like "t" for translated and "u" for
untranslated); Icon has been ported to platforms that can't even spell libc,
let alone support it.

> note that in these days of LANS, the issue is yet more complex. It would
> be dandy if I could read text any old text file and have it look sane, but
> I may be writing it to a different machine without any way of knowing
that.

So where's the problem?  No matter *what* machine you end up on, Python
could read the thing fine.  Or are you assuming some fantasy world in which
people sometimes run software other than Python <wink>?

Caveat:  give the C std a close reading.  It guarantees much less about text
mode than anyone who hasn't studied it would believe; e.g., text mode
doesn't guarantee to preserve chars with the high bit set, or most control
chars either (MS's treatment of CTRL-Z as EOF under text mode conforms to
the std!).  Also doesn't guarantee to preserve a line-- even if composed of
nothing but printable chars --if it's longer than 509(!) characters.

That's what I mean when I say stdio's text mode is a bad joke.

> When I bother to manipulate these things, I usually choose to use
> *nix style text files. But I don't deal with Macs, and the only
> common Windows tool that can't deal with plain \n is Notepad.

I generally create text files in binary mode, faking the \n convention by
hand.  Of course, I didn't do this before I became a Windows Guy <0.5 wink>.

> and-stripcr.py-is-everywhere-available-on-my-Linux-box-ly y'rs

A plug for my linefix.py (Python FTP contrib, under System), which converts
among Unix/Windows/Mac in any direction (by default, from any to Unix).

who-needs-linux-when-there's-a-python-in-the-window-ly y'rs  - tim