Hello, this post is half a question, half a proposal. Q: what happens to the filesystem file, and to the python file object below? text = file(fn).read() (used 'file' instead of 'open' in purpose) Note that there seemingly is no way to close or del the file object, nor even to check its 'closed' flag. I would expect that, in the case a file remains unnnamed, it is automatically closed and del-ed. If not, do you think it is sensible to ensure that? In this case, we have a both safe and compact idiom to read file content. I consider this good, because the concept of "read file content" is both a single and simple operation -- and rather common. Else, I would propose a pair of string methods (rather than 2 more builtin funcs) .filetext() & .filebytes(). In both cases, the target string is (supposed to be) a filename. Below an example. =================== class FString(str): ''' custom string implementing file content reading ''' TEXT_MODE = 'r' BYTES_MODE = 'rb' NO_FILE_MESSAGE = 'Cannot open file "%s".' def filetext(self): return self._filecontent(FString.TEXT_MODE) def filebytes(self): return self._filecontent(FString.BYTES_MODE) def _filecontent(self, mode): try: f = open(self, mode) except IOError,e: raise ValueError(FString.NO_FILE_MESSAGE % self) bytes = f.read() f.close() return bytes ===================
from FString import FString fn = FString("test.txt") fn.filetext() 'foo\nbar\n' fn.filebytes() 'foo\nbar\n' fn = FString("fool.txt") fn.filetext() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "FString.py", line 12, in filetext raise ValueError(NO_FILE_MESSAGE % fn) ValueError: Cannot open file "fool.txt". ===================
I take the opportunity to ask whether there is a chance in the future to be able to customize builtin types. (In this case many proposals on this list will simply vanish.) Denis ------ la vita e estrany
On Sat, Jun 13, 2009 at 1:25 AM, spir<denis.spir@free.fr> wrote:
Hello,
this post is half a question, half a proposal.
Q: what happens to the filesystem file, and to the python file object below?
text = file(fn).read()
(used 'file' instead of 'open' in purpose) Note that there seemingly is no way to close or del the file object, nor even to check its 'closed' flag. I would expect that, in the case a file remains unnnamed, it is automatically closed and del-ed. If not, do you think it is sensible to ensure that?
Indeed, that is what happens. However, the language makes no guarantees as to exactly *when* it will be GC-ed and closed; there's nothing to ensure it will be closed in anything approaching a timely manner, which could cause problems in the case of long-running programs and/or programs that open many files. It is true that for CPython, the file object will happen to be GC-ed immediately, but this is mere implementation-specific behavior (due to refcounting being employed) and probably ought not to be relied upon; IronPython, for instance, does not behave the same way.
In this case, we have a both safe and compact idiom to read file content. I consider this good, because the concept of "read file content" is both a single and simple operation -- and rather common.
Actually, we already have something for that. And it's only 1 extra line: with f as file(fn): text = f.read() #when execution reaches here, the file is guaranteed to be closed Though personally I think dealing with individual lines in a file is more common than slurping in an entire file's contents all at once. But I digress.
Else, I would propose a pair of string methods (rather than 2 more builtin funcs) .filetext() & .filebytes(). In both cases, the target string is (supposed to be) a filename.
Probably unnecessary seeing as we have the above idiom.
I take the opportunity to ask whether there is a chance in the future to be able to customize builtin types. (In this case many proposals on this list will simply vanish.)
I think you'll have to elaborate on what exactly you mean by "customizing builtin types" for anyone to answer your question fully. Assuming you mean "modify, replace, or extend in-place", I think the prospects of that are rather grim; Python is not Ruby or Lisp. Cheers, Chris -- http://blog.rebertia.com
Le Sat, 13 Jun 2009 10:25:19 +0200, spir <denis.spir@free.fr> s'exprima ainsi:
Hello,
this post is half a question, half a proposal.
Q: what happens to the filesystem file, and to the python file object below?
text = file(fn).read()
(used 'file' instead of 'open' in purpose) Note that there seemingly is no way to close or del the file object, nor even to check its 'closed' flag. I would expect that, in the case a file remains unnnamed, it is automatically closed and del-ed. If not, do you think it is sensible to ensure that?
Actually, I could have answered my own question, at least for the current CPython implementation:
file("test.txt").read() 'foo\nbar\n' file("test.txt",'r') <open file 'test.txt', mode 'r' at 0xb7dbbbf0>
Seems to shows the file has been closed. Denis ------ la vita e estrany
spir wrote:
.... Actually, I could have answered my own question, at least for the current CPython implementation: ....
Warning: experimentation only gets you to the behavior of a particular implementation on your machine at the time you run it. If you don't encounter a bug, it also gives you a _sample_ of _acceptable_ behavior. It cannot, however get you to the definition of the the behavior. For that you _must_ read the documentation. If you rely on experimentation, you will come to depend on a lot of things that might very well change. At best, your program will be much less portable, and at worst, the program will work perfectly until you demo or deliver your program. --Scott David Daniels Scott.Daniels@Acm.Org
On Sat, Jun 13, 2009 at 8:05 AM, spir<denis.spir@free.fr> wrote:
Le Sat, 13 Jun 2009 10:25:19 +0200, spir <denis.spir@free.fr> s'exprima ainsi:
Hello,
this post is half a question, half a proposal.
Q: what happens to the filesystem file, and to the python file object below?
text = file(fn).read()
(used 'file' instead of 'open' in purpose) Note that there seemingly is no way to close or del the file object, nor even to check its 'closed' flag. I would expect that, in the case a file remains unnnamed, it is automatically closed and del-ed. If not, do you think it is sensible to ensure that?
Actually, I could have answered my own question, at least for the current CPython implementation:
file("test.txt").read() 'foo\nbar\n' file("test.txt",'r') <open file 'test.txt', mode 'r' at 0xb7dbbbf0>
Seems to shows the file has been closed.
How so? Reading a file isn't exclusive on any major Python platform. You can get file locking on various platforms by using platform-specific file locking calls, but that's not the default for Python. - Josiah
spir <denis.spir@free.fr> wrote:
I take the opportunity to ask whether there is a chance in the future to be able to customize builtin types. (In this case many proposals on this list will simply vanish.)
Assuming I understand your question correctly, then according to a recent posting on python-dev[1], builtin types not being modifiable is a policy decision. According to Guido, it is so that 3rd party modules cannot make incompatible changes to built-in types. So the answer to your question is most likely "no". --David [1] http://mail.python.org/pipermail/python-dev/2009-June/090044.html
participants (5)
-
Chris Rebert -
Josiah Carlson -
R. David Murray -
Scott David Daniels -
spir