[Python-Dev] RE: Python on Windows chapter.
Thu, 15 Jul 1999 03:00:18 -0400
>> ... The case for abandoning the CRTL's text mode gets stronger
>> and stronger!
> 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
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