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

[Peter Funk]

Hi,

Jeremy Hylton wrote:
[...]
> Feel free to think of it as a guide, but don't think of it as a
> specification!  (It is, as you mention, fairly old.)  The only
------------------------------------------^^^^^^^^^^^
This was my argument to harden Moshes point, that *MUCH* code written
until today relies on this advertised behaviour!

> official word on reclaiming externel resource is the Python Language
> Reference -- http://www.python.org/doc/current/ref/.
> 
> >Some objects contain references to "external" resources such as open
> >files or windows. It is understood that these resources are freed when
> >the object is garbage-collected, but since garbage collection is not
> >guaranteed to happen, such objects also provide an explicit way to
> >release the external resource, usually a close() method. Programs are
> >strongly recommended to explicitly close such objects. The
> >`try...finally' statement provides a convenient way to do this.
> 
> If this isn't clear enough, we could revise it for the next release of
> the documentation.  As Guido said, the code is broken, not JPython.

Thank you: This paragraph is indeed clear enough. :-(

And I must admit, that the above cited paragraph is at least as old
as Mark Lutz book (I've just restored Python1.2/Doc to check this out, 
since I couldn't believe that in the first place: damned time machine!)
I must have overlooked this particular paragraph in the past
and so may many other users of Python (At least Mark Lutz ;-) ?)

However I disagree with this paragraph.

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.  

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.  And in
GUI programs you usually have *many* objects, that keep external
resources like windows, files and the like.

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)

For me all those nifty new features currently discussed here (augmented ass., 
list comprehensions...) are not all *that* useful, compared to this important 
convience of the current C-Python implementation.  

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)