Paul Rubin wrote:
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> > I disagree, somewhat. No, you shouldn't count on the "ref count" per
> > se going to 0. And you shouldn't count on the file object being GC'd
> > _immediately_ after the last reference is destroyed. You should be able
> > to rely on it being GC'd at some point in the not-horribly-distant
> > future, though.
>
> Is there something in the language specification that says I should be
> able to rely on something like that?
No, as I said I know the language spec doesn't require any GC at all.
> In Jython, for example, I think
> GC is handled totally by the underlying JVM and therefore totally up
> to the Java implementation.
Sure. But most Java GCs are pretty reasonable and for typical code
will run periodically (what I call the not-horribly-distant future).
> > Doing an explicit .close() is not normally useful and muddies the code
> > (and introduces more lines for potential bugs to infest).
>
> Yes, the "with" statement is the right way to do it.
Ugh.
> > And yes, I know that the language spec technically allows for no GC at
> > all--it's a QOI issue, not a spec issue, but any implementation that
>
> QOI?
Sorry, I had introduced and defined it earlier but wound up editing out
that sentence. Quality of implementation.
> > didn't GC would be useless as a general Python platform (perhaps useful
>
> GC's typically track memory allocation but not file handle allocation.
> If you're opening a lot of files, you could run out of fd's before the
> GC ever runs.
Yes, if you're opening lots of files quickly without giving the GC time
to work then you may be stuck having to use some hack to support
non-refcounting implementations (or simply deciding that the cost of
doing so is not worth supporting implementations with nondeterministic
GC). Yet another reason I said:
> > (And personally I think the benefits to programmers of guaranteeing
> > ref-counting semantics would outweigh the additional headaches for
> > Jython and other alternative implementations).
>
> Yes, "with" (doing an implicit close guaranteed to happen at the right
> time) takes care of it properly.
In many cases, that's adding additional programmer burden to duplicate
information about an object's lifetime that's already in the code. In
simple cases, it uglifies the code with what should be an unnecessary
statement (and adds additional layers of indentation).
Guaranteeing ref-counting semantics at least for local variables when
you return from a function makes for more readable code and makes life
easier on the programmer.
It's obvious to the reader that in code like:
def myFunc(filename):
f = open(filename, 'r')
for line in f:
# do something not using f
that f is used only in myFunc. Indeed, such scoping is a big part of
the point of having functions, and having to duplicate scope
declarations (via with statements or anything else) is broken.
Having f destructed at least when the function returns makes for more
readable code and fewer mistakes. CPython's refcounting behaves very
nicely in this regard, and Python programmers would be much better
served IMO if the language required at least this level of
sophistication from the GC (if not full ref-counting).
--
http://mail.python.org/mailman/listinfo/python-list
