Abstracting try..finally with generators (instead of macros)

[Oren Tirosh]

On Sun, Dec 15, 2002 at 07:41:11PM +0200, Beni Cherniavsky wrote:
> > Generators with side effects would greatly benefit from a defining
> > try:..finally around yield.  It is possible to define sensible semantics
> >  for it - to be executed when the last reference to the iterator is
> > deleted (if `.next()` wasn't called).  I strongly vote for it.  Any
> > chance for Python 2.3?
> >
> Correction: such semantics can't work with Jython beacuse it doesn't
> guarantee finalization at predictable times.  

My patch http://python.org/fs/584626 has been rejected because of this.
The Python language != the CPython implementation.

> The best alternative I see
> is augmenting the definition of the for loop to make explicit finilization
> effort on iterators that support it (see below for how).  It should only
> happen on iterators having the appropriate method (similarly to how for
> falls back to __getitem__ when __iter__ is absent).  

+1

Actually, +0.5. There is a problem with this approach. What about 
programmers using next() directly? Their code will become retroactively 
incorrect because they do not finalize their iterators.

Should an iterator's finalize() method be called automatically when its
reference count drops to 0?

> Maybe this should be added to PEP 288?

-1 

Adding things to an existing PEP generally decreases their chances of 
acceptance. Write your own PEP.

> If multiple exceptions indeed are dropped, I propose a new name for the
> method:  `.finalize()`.  This makes more sense when the intent is to
> trigger only try..finally statements.  If not, calling without arguments
> is already defined.  Maybe having both `.finalize()` and `.throw()` is a
> good idea.

+1 on .finalize()

> http://sourceforge.net/mailarchive/forum.php?thread_id=386835&forum_id=2445
> and
> http://sourceforge.net/mailarchive/forum.php?thread_id=765404&forum_id=2445
> so I'm not the first to invent this...  Surprisingly Guido himself
> suggested to rely on __del__ in a reply to the later link.  Is there an
> accepted approach of "use __del__ and ignore JPython" or was it simply
> from lack of better solution?

A programmer may choose to use things that only work in CPython, but the
Python language makes no guarantees. Some future version of CPython might 
even give up reference counting and use garbage collection only, resulting
in unpredictable finalization.

	Oren