wishlist: more general file objects, and some doc improvements

[Haimo G. Zobernig]

Hi,

 I've been using Python for a while with good success, and although I 
once in a while come across something I'd like to have changed in the
language, I usually refrain from asking for it (usually others have done
so already, and met with a well-reasoned response from Guido or others
as to why it's not such a good idea...). Anyway, in a recent project I
needed to do a lot of file handling and found that I would have benefitted from
a more general and more symmetric behaviour of file objects (see point 1 below).
Haven't seen any request similar to mine.   

 Also, while perusing the online documentation, I realized that a few things in
the tutorial about input that had confused me when I first learned Python are
still the same way, hence I'm suggesting some changes there (point 2). So...

1) file objects:

   Currently you create a file object by using the open() function e.g.

   f = open("myfile.txt","r")

   later you can apply that object's methods e.g. f.write(), f.close() 
   But this is not very symmetric nor object oriented. 
   I would like to be able to create file objects independent of whether 
   the file is being opened, or whether it exists at all. Something like

   f = file("myfile.txt") 

   file object f should then also have an open() method
   and a number of attributes such as exists(), is_open(), etc.
   so that later I can do things like

   for f in list_of_files:
      if f.exists():
         f.open("r")
         x = f.readlines()
         f.close()
      else:
         f.open("w")
         f.write(some_data)
         f.close()

   It might also be useful to provide a "inquire" method which could 
   e.g. return a dict of a file's currently known properties, with a 
   subset of properties being defined on all supported platforms, and       the
others being platform dependent.

   Of course, all of the above can be done now differently, but I'd
   prefer such a more symmetric approach. Also, it seem this can be 
   implemented without invalidating any of the current file handling 
   methods. It's just an extension.

2) One thing that in the beginning confused me quite a bit is that the
   tutorial doesn't actually tell the beginner much about how to do 
   input. Well, there is chapter 7, Input and Output. But it only spends
   two sentences, both relating only to *output*, before going on to 
   ch. 7.1, Fancier Output Formatting (again, nothing on *input* here)
   We don't get to know anything about input until ch. 7.2, Reading and
   Writing Files - but it's truly just about files. How can a newbie        know
what to use just to get input from the console (keyboard)?
   The library reference doesn't make this information easily available    
either.

   I propose to add in the currently very short text of ch. 7, before
   7.1, a short explanation with examples, of 
   -  print   
       output, this has already been used before in the tutorial
   -  raw_input
       the input analog of print, but which beginner would guess the           
"raw_" part?  

   I know "input" exists and does the equivalent of                        
eval(raw_input()), but I would much prefer to have the names            
changed, after all how often is input really used?
       raw_input ---> input
       input     --->  eval_input
       ( I'm aware such a change would have to wait for Python 2.0 ) 

Ok, enough for now.
Hope these are useful suggestions.

   Haimo G. Zobernig

Haimo.Zobernig at cern.ch