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

[Beni Cherniavsky]

On 2002-12-15, Oren Tirosh wrote:

> 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.
>
s/fs/sf/.  Hmm, I should google more thoughfully, missed this one ;-)

> > 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.
>
Well, iterators that require finalization should be documented as such.
After some reading I see that this is Python's general approach.  Implicit
finalization can't be trusted.

The for loop seems to be the only construct which holds an iterator
without exposing it to user code so it must have this finalization
support.  Besides, a for loop is the most common way to use iterators.

> Should an iterator's finalize() method be called automatically when its
> reference count drops to 0?
>
No, IMHO.  That would encourage sloppy practices and later headache.

> > 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.
>
I see.  However this extends PEP 288 in a natural way.  Just forking it
would make the division into PEPs arbitrary.  However, PEP 288 needs a
split anyway - the atribute access and exception causing are completely
independent.  If writing a new PEP, the later should move into it.

> > 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.
>
I just did when starting this thread :-).  I was just surprised to see
Guido do it.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>