arve.knud...@gmail.com a écrit :
On Oct 19, 4:14 pm, Grant Edwards <inva...@invalid.invalid> wrote:
On 2009-10-19, arve.knud...@gmail.com <arve.knud...@gmail.com> wrote:
I thought that file objects were supposed to be
garbage-collected and automatically closed once they go out of
scope,
At some point after they go out of scope, they will be.
Eventually. Exactly when is an implementation detail.
at least that's what I've been told by more merited Python
programmers. I'm also quite sure that this is quite a common
assumption in various programs,
AFAICT, the file descriptor associated to the file object will be freed
when the CPython process will finish - which implies you're using the
CPython interpreter. This doesn't mean the file is garanteed to be
closed _at the point where you're trying to os.remove() it_. And as I
said, this is a CPython implementation detail - not a language
specification. Jython or IronPython (or any other implementation) may
not work that way.
If your program relies on the assumption that some particular
object will be garbage-collected between points A and B, then
that's a bug in your program. If you depend on the fact that
some object has been delted, then "del" it. If you depend on
the fact that a file is closed, then close it.
Personally I am against that assumption, and prefer a utility function
which reads the file and automatically closes it in a "finally" block
(in lieu of the "with" keyword).
What's your problem with the with ???
But anyway : explicitely releasing resources such as files, network
connections etc is of course the RightThing(tm), except eventually in
one-shot throwaway scripts.
However, when providing a patch for a
high-profile opensource Python project I was scolded for going to such
lengths, as the prescribed style was to just open files and let them
be closed implicitly.
Err... Care to name the project ? I hope it's not one I ever advertized :(
--
http://mail.python.org/mailman/listinfo/python-list
