file object, details of modes and some issues.

[Peter Hansen]

simon place wrote:
> 
>      'b', all modes can have a 'b' appended to indicate binary mode, i think this
> is something of a throw-back to serial comms ( serial comms being bundled into
> the same handlers as files because when these things were developed, 20+ years
> ago, nothing better was around. ) 

It has nothing to do with serial communications, AFAIK.

> Binary mode turns off the 'clever' handling
> of line ends and ( depending on use and os ) other functional characters (
> tabs expanded to spaces etc ), the normal mode is already binary on windows so
> binary makes no difference on win32 files. 

I think this is mostly wrong.  The normal mode on windows is *text*, not
binary, so it very much makes a difference.  Also, I've never heard 
of binary mode having *any* effect on tabs, spaces, etc., other than
the newline character(s), so could you please provide a reference.  Or
was this supposition on your part?

> But since in may do on other
> o.s.'s, ( or when actually using the file object for serial comms.) i think
> you should actually ALWAYS use the binary version of the mode, and handle the
> line ends etc. yourself.

Your program will not be portable if you do this.  Use text mode on text 
files and binary mode on binary files.  Understand the difference, so you 
know when to use which.

> suffice to say, i wasn't entirely impressed with the python file object

Where is your programming background from?  I've never used a language where
the "file object" or equivalent did anything more than, let alone even as much as,
the Python file object.  (Not intended as an insult, just pure curiosity.)

> i remembered the cross platform problems its dealing with and all
> the code that works ok with it, and though i'd knock up this post of my
> findings to try to elicit some discussion / get it improved / stop others
> making mistakes.

A laudable goal.  Let the discussion ensue! :-)

-Peter