"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> I disagree strongly with this assertion. It's not as efficient overall
> as other GC implementations, but it's not a case of "less efficient to
> do the same task". Reference counting buys you deterministic GC in the
> pretty common case where you do not have circular references--and
> determinism is very valuable to programmers. Other GCs be faster, but
> they don't actually accomplish the same task.
GC is supposed to create the illusion that all objects stay around
forever. It releases unreachable objects since the application can't
tell whether those objects are gone or not.
Closing a file is a state change in which stuff is supposed to
actually happen (buffers flushed, CLOSE message sent over socket,
etc.) That's independent of releasing it. In your example
(simplified):
def func(x):
f = open_some_file(x)
# do stuff with f
it might even be that the open call saves the file handle somewhere,
maybe for logging purposes. You presumably still want it closed at
function exit. The GC can't possibly do that for you. Relying on GC
to close files is simply a kludge that Python users have been relying
on, because doing it "manually" has been messy prior to 2.5.
> I can come up with plenty of "superior" algorithms for all kinds of
> tasks if I'm not bound to any particular semantics, but losing
> correctness for speed is rarely a good idea.
Then don't write incorrect code that relies on the GC's implementation
accidents to make it work ;-). PEP 343 really is the right way to
handle this.
--
http://mail.python.org/mailman/listinfo/python-list
