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

M.-A. Lemburg mal@lemburg.com
Fri, 19 Nov 1999 10:08:44 +0100


Mark Hammond wrote:
> 
> [MAL]
> 
> > 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.
> 
> Breaking existing code that works should be considered more than a
> nuisance.

Its an error that pretty easy to fix... that's what I was
referring to with "nuisance". All you have to do is open
the file in binary mode and you're done.

BTW, the change will only effect platforms that don't differ
between text and binary mode, e.g. Unix ones.
 
> However, one answer would be to have "t#" _prefer_ to use the text
> buffer, but not insist on it.  eg, the logic for processing "t#" could
> check if the text buffer is supported, and if not move back to the
> blob buffer.

I doubt that this is conform to what the buffer interface want's
to reflect: if the getcharbuf slot is not implemented this means
"I am not text". If you would write non-text to a text file,
this may cause line breaks to be interpreted in ways that are
incompatible with the binary data, i.e. when you read the data
back in, it may fail to load because e.g. '\n' was converted to
'\r\n'.
 
> This should mean that all existing code still works, except for
> objects that support both buffers to mean different things.  AFAIK
> there are no objects that qualify today, so it should work fine.

Well, even though the code would work, it might break badly
someday for the above reasons. Better fix that now when there
aren't too many possible cases around than at some later
point where the user has to figure out the problem for himself
due to the system not warning him about this.
 
> Unix users _will_ need to revisit their thinking about "text mode" vs
> "binary mode" when writing these new objects (such as Unicode), but
> IMO that is more than reasonable - Unix users dont bother qualifying
> the open mode of their files, simply because it has no effect on their
> files.  If for certain objects or requirements there _is_ a
> distinction, then new code can start to think these issues through.
> "Portable File IO" will simply be extended from simply "portable among
> all platforms" to "portable among all platforms and objects".

Right.

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