When a frame's f_locals attribute is accessed, one of two things happens:

  * If this is the first access, a new dictionary is created and it is
populated with the locals from the frame (since they are not stored
internally as a dictionary).  The dictionary is both saved and returned.
  * Otherwise, the previously saved dictionary is updated to reflect the
current locals of the frame and then returned.

This means that the lifetime of locals in the frame is strangely altered
if the frame's f_locals attribute is ever accessed.  In particular, the
locals are kept alive until the frame object is discarded or the
f_locals attribute is accessed again.

The drawback of this is that references to locals may be "leaked" in a
surprising and difficult to understand way.  Another is that when
debugging an application, this will cause objects to have a different
lifetime than they will when the application is run without the
debugger.  One way the former of these issues has manifest is described
in this Twisted bug report:

  http://twistedmatrix.com/trac/ticket/3853

There, I suggested three possible solutions, in the form of a
replacement API for the f_locals attribute which either:

    * Gave you a copy of the locals at the current time and didn't
pretend it would be automatically updated
    * Gave you a view onto the locals at the current time, instead of a
real dictionary, and didn't actually hold any references to the locals
itself, only granted access to the "canonical" locals data in the frame.
    * Gave you a real dictionary of the locals but didn't hold a strong
reference to that dictionary internally, so that if all external users
of the dictionary went away, the frame itself would also stop referring
to the locals.