file object, details of modes and some issues.

[simon place]

Peter Hansen wrote:
> 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.
> 
> 

perhaps too big a leap in one go, how about

text file -> ascii file -> control codes  -> teletype  ->  serial comms

( never noticed how ascii characters below 32 have serial comms references.)

>>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?
> 
> 

No, what i said was that binary mode does NOT do things.

on windows, and msdos, files seem to be handled more separately to serial
comms than on some other systems and so files bypass any control code
processing , that's why i said its effectively already binary mode for files.

But generally using binary mode is more compatible, although i understand the
reasoning which makes someone think that text mode was more x-platform.

>>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.
> 
> 

i don't think i'm the one with a shallow grasp of these things.

but, to be helpful, how about you come up with an example of when 'text' mode 
as opposed to 'binary and handle the line end', is helpful for portability.

>>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.)
> 

never heard of VB.,

	open 'file' for random access lock write #1

python,ind.comms,web,databases,java,vb,windows,fortran,pascal,msdos,8086,z80,6502

I've seen all sorts of changes made to sequential data because of control
codes. Although most file systems have lost virtually all the processing
effects, for compatibility and flexibility, use binary, and handle the line ends.

>>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