[Python-Dev] file modes (was: just say no...)

[M.-A. Lemburg]

Greg Stein wrote:
> 
> On Thu, 18 Nov 1999, M.-A. Lemburg wrote:
> > Tim Peters wrote:
> > > [MAL]
> > > > File objects opened in text mode will use "t#" and binary
> > > > ones use "s#".
> > >
> > > [Greg Stein]
> > > > ...
> > > > The real annoying thing would be to assume that opening a file as 'r'
> > > > means that I *meant* text mode and to start using "t#".
> > >
> > > Isn't that exactly what MAL said would happen?  Note that a "t" flag for
> > > "text mode" is an MS extension -- C doesn't define "t", and Python doesn't
> > > either; a lone "r" has always meant text mode.
> >
> > Em, I think you've got something wrong here: "t#" refers to the
> > parsing marker used for writing data to files opened in text mode.
> 
> Nope. We've got it right :-)
> 
> Tim and I used 'r' and "t" to refer to file-open modes. I used "t#" to
> refer to the parse marker.

Ah, ok. But "t" as file opener is non-portable anyways, so I'll
skip it here :-)
 
> >...
> > I guess you won't notice any difference: strings define both
> > interfaces ("s#" and "t#") to mean the same thing. Only other
> > buffer compatible types may now fail to write to text files
> > -- which is not so bad, because it forces the programmer to
> > rethink what he really intended when opening the file in text
> > mode.
> 
> It *is* bad if it breaks my existing programs in subtle ways that are a
> bitch to track down.
> 
> > Besides, if you are writing portable scripts you should pay
> > close attention to "r" vs. "rb" anyway.
> 
> I'm not writing portable scripts. I mentioned that once before. I don't
> want a difference between 'r' and 'rb' on my Linux box. It was never there
> before, I'm lazy, and I don't want to see it added :-).
> 
> Honestly, I don't know offhand of any Python types that repond to "s#" and
> "t#" in different ways, such that changing file.write would end up writing
> something different (and thereby breaking existing code).
> 
> I just don't like introduce text/binary to *nix platforms where it didn't
> exist before.

Please remember that up until now you were probably only using
strings to write to files. Python strings don't differentiate
between "t#" and "s#" so you wont see any change in function
or find subtle errors being introduced.

If you are already using the buffer feature for e.g. array which 
also implement "s#" but don't support "t#" for obvious reasons
you'll run into trouble, but then: arrays are binary data,
so changing from text mode to binary mode is well worth the
effort even if you just consider it a nuisance.

Since the buffer interface and its consequences haven't published
yet, there are probably very few users out there who would
actually run into any problems. And even if they do, its a
good chance to catch subtle bugs which would only have shown
up when trying to port to another platform.

I'll leave the rest for Guido to answer, since it was his idea ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    43 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/