Python 2.0 (perhaps off topic)

[Jeremy Hylton]

>>>>> "PP" == Paul Prescod <paul at prescod.net> writes:

  PP> Jeremy Hylton wrote:
  >>  Perhaps this is what I get for jumping in in the middle of a
  >> conversation without learning how it got started.  The example I
  >> was responding to depended on file object being immediately
  >> finalized to avoid leaking file descriptors.

  PP> This is a documented feature of Python (documented in the FAQ at
  PP> least).  New users do not currently need to learn otherwise

That doesn't count!  Among other reasons, the FAQ predates JPython.
Guido and Jim spent some time going through the differences between
CPython and JPython, and deciding which of the differences where
legitimate and which were bugs or incompatibilities.  I believe that
memory management is one of those implementation-dependent issues that 
the language semantics do not specify.

  PP> unless they use JPython which is incompatible in this regard. In
  PP> other words, this IS a demonstration of a flaw in GC, or at
  PP> least in Java GC because it required a change in the Python
  PP> language semantics.

Don't think it's fair to call it a change-- just a clarification.  Nor 
would the problem necessarily lie with the garbage collector.  If the
language spec had said that finalizers were always called such that
you could depend on it to free resources like file descriptors, then
it would have been a bug in the spec <0.1 wink>.

  PP> I think that that is all anyone has been saying. Many people
  PP> like the current semantics and don't trust that a full GC would
  PP> deterministically invoke finalizers for arbitrary resources.

I'm sure it wouldn't, but as the FAQ entry you mentioned explains,
there are some exceptions with reference counting, too.  In general,
it's a rather risky to depend on the finalizers to close resources for 
you.  Even with reference counting, it's easy to have one more
reference than you think and not have some files get closed.

Jeremy