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

[Peter Funk]

Hi,

Guido van Rossum:
> > 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.

In a GUI this is usually the case:  For example Pmw contains such
a default handler, which catches all otherwise uncaught exceptions
and prevents the application from bombing.

> Normally it becomes the totally acceptable
> 
> 	ref = constructor("foo")
> 	func(ref.method())
> 	ref.close()

Sigh.  This is still a factor of three.  But LOCs are not my major
point:  An application programmer has to know, whether the object
in question uses external resources or not, or he has to use the
inconvinient 'close()' or 'destroy()' anyway, if he want's to make sure.

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

Only if the "constructor().method()" idiom is not contained in a loop.  
Ancient Unix systems allowed only 20 files open at the same time.  Although 
this has been increased to 120 or so in the mean time, you will easily ran 
out of file descriptors with the simple throw-away script posted in my 
first rant in this thread:

>>> import os, rfc822
>>> posters = {}
>>> for arti in os.listdir('/var/spool/news/comp/lang/python'):
...     poster = rfc822.Message(open(arti)).get("From")    
...     posters[poster] = posters.get(poster, 0) + 1
... 
>>> for poster, howoften in posters.items():
...     print poster, "posted", howoften, "times to clp."
...

I believe scripts like this one are very common in the industry, since
this idioms were advertised by several books (I still have to look
up Martin v.Loewis "Das Pythonbuch", but IRC it contained subsection
comparing Pythons garbage collection with Java GC and advertised
the advantages of ref count GC)

> > 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.

May be.  Since Tkinter has been ported to JPython, I theoretically
could give this platform at least a try.  But now I know in advance,
where I've to expect serious problems.  I believe a lot of my GUI
code based on Tkinter/Pmw makes use of this behaviour which simply
works as advertised by Mark Lutz (and possibly others).
[...]
> Listen, I'm sorry for causing your worldview on this point to
> collapse, but it's no big deal, okay?!

If it is only *my* worldview: sure.  But their might be others, who have 
learned Python 3 or 4 years ago.  May be by using C-Python, may be by 
using Mark Lutz book "Programming Python".

Since C-Python is available on all major platforms and the implementation
in fact guarantees this behaviour (Pheeew!), this is indeed no big deal.  
No need to use 'JPython'. ;-)

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)