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
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:
yieldpostpones 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
statements run, as they'll appear to run well after they 'should'
(and when they did when your function wasn't using
(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
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.
(Credit where credit is due department: I was exposed to this issue by Using yield Statements in WSGI Middleware can be Very Harmful.)