== _try:/finally:_ and generators

Suppose that you have code that generates an abstract 'list' of some
sort and returns it inside a _try:/finally:_ block. There are two common
ways to code this; you can return a real list, or you can use _yield_ to
be a generator. You might even code it one way and change it to the other
later, which is generally a transparent change.

Not this time, though. If you are using _finally:_, the two options can
have quite different behavior. Constructing an example is tedious, but
explaining the issue is simple:

> Using _yield_ postpones the execution of your _finally:_ blocks from
> when your results are generated and returned to when your results are
> *used*, which may be some time later.

In simple situations you won't notice this, because the results are used
immediately after they're returned. In more complex situations you'll
probably get mysterious ordering issues about when your _finally:_
statements run, as they'll appear to run well after they 'should'
(and when they did when your function wasn't using _yield_).

(For example, consider a _finally:_ that closes down a database
connection. If the result of your database lookup function is just put
in a data structure and only looked at later, you could build up a lot
more database connections than you expect.)

In fact this is one part of a general issue: when you use _yield_,
all of the objects and resources held alive by your function are only
released when your results are used. Effectively _yield_ turns your
ordinary function into a closure, [[with the resulting consequences for
potential resource leaks DebuggingPythonMemoryLeaks]].

(Credit where credit is due department: I was exposed to this issue
by [[Using yield Statements in WSGI Middleware can be Very Harmful
http://jimmyg.org/blog/2009/using-yield-statements-in-wsgi-middleware-can-be-very-harmful.html]].)