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@cern.ch
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
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@cern.ch