automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration)

Guido van Rossum guido@beopen.com
Sun, 30 Jul 2000 10:42:49 -0500


> IMO one of the major strenghts of Python (in its reference implementation 
> C-Python) has today compared to other languages (Java) is this particular
> behaviour.  

["this behavior": closing files as soon as they go out of scope]

> The argument made in the last sentence of the paragraph cited from
> the reference manual is bogus:  In order to be able to call a close() 
> method you have to keep an explicit reference to the object in question.  
> This usually requires many lines of source code where previously only 
> one line was needed:
> 
> 	func(constructor("foo").method())
> has to be recoded as
> 	try:
> 	    ref = constructor("foo")
> 	    func(ref.method())
> 	finally:
>             ref.close()
> if constructor happens to keep external resources.  This is a factor of
> five (in LOC) of code bloat and is absolutely unacceptable.

Only if you expect that func() may fail *and* that there may be an
outer try/except that keeps the program alive for much longer.

Normally it becomes the totally acceptable

	ref = constructor("foo")
	func(ref.method())
	ref.close()

I would recommend the try/finally version only if func() is *expected*
to fail for some I/O related reason.

And in much Python code (e.g. most scripts and throw-away programming)
even the one-liner is totally acceptable.

> If this kind of coding is required to make existing Python apps running
> reliable under 'JPython', then this will render 'JPython' (and any other 
> Python implementation without proper reliable reclaiming) pretty useless 
> for me.  (and may be to other members of the Python community)

This sounds like a bit of an exaggeration to me.

The fact of the matter is that we can't guarantee this, and in fact
there are lots of gotcha's with expecting this behavior (e.g. when you
catch an exception while a file object is local, the exception
handling may easily keep it alive longer than expected.  It's also
very easy to forget other references to the object.

Listen, I'm sorry for causing your worldview on this point to
collapse, but it's no big deal, okay?!

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)