On 8/12/2006 1:53 PM, Gabriel Genellina wrote: > At Thursday 7/12/2006 15:44, John Machin wrote: > >> > > > ftxt=open(filename,"rt") >> > > >> > >Is this a bug or a feature? Or is it one of those good old >> "unspecified >> > >behaviour" cases? MSVC rtl only? >> > >> > The Python docs say only that the initial letter is checked. And the >> > ANSI 89 C says that other characters may follow after r, r+, etc. >> > "rt" is useless for an ANSI C compiler, since the default stream mode >> > is "text" -on systems which differentiate between text and binary- >> > and irrelevant on systems which don't do such distinction. >> > (And since I got used to write "rt", >> >> Why did you do that? >> (1) Text mode is was and ever shall be the default, even with MS. > > No, there used to be a flag in the stdio library, giving the default > value when neither t or b was specified. > For the Borland C++ 3.1 help (about 1991): > If "t" or "b" is not given in the string, the mode is governed by _fmode. > If _fmode is set to O_BINARY, files are opened in binary mode. > If _fmode is set to O_TEXT, they are opened in text mode. > MSC used to have a similar flag (perhaps using the same name).
Indeed, and their docs say that the default for _fmode is text mode. > All of this predates wide usage of ANSI C 89, which made the "t" flag > obsolete. > >> (2) Seeing we're referring to docs and standards: Microsoft C 5.0 >> Optimizing Compiler, Run-Time Library Reference manual says "The t >> option is not part of the ANSI standard for open, but is a Microsoft >> extension and should not be used where ANSI portability is required". > > A "t" after the initial recognized characters should be ignored by any > conforming compiler. I think the idea was to allow for extensions like > fopen(fn, "rt;reclen=128") but except esoteric platforms I doubt anyone > is using that. So it should be ignored. So, back to the question: why did you get into the habit of writing "rt" when it was pointless? -- http://mail.python.org/mailman/listinfo/python-list
