Having poked around a little bit, I found it's not
simple to get at the contents of a cell object from
Python. It's not the sort of thing that one needs to be
doing very frequently, but I've run into a few
situations recently where it would be really useful
from a debugging standpoint.

You can get at a cell object containing a given value
by making a quick closure and looking at the
func_closure attribute:

  (lambda x: lambda: x)(some_value).func_closure[0]

but there's not anything we can easily do with that
object to find out what it's pointing at. The str()
representation only tells us the id of the contained value.

This trivial patch creates a "value()" method for cell
objects that returns a new reference to the contained
object, for introspection purposes.

I should mention it's not the only way to accomplish
this; you can also get at the contents of a cell by
creating a new function from a code object and
manufacturing its func_closures tuple from the cell you
already have:

def get_cell_value(cell):
    return type(lambda: 0)(
        (lambda x: lambda: x)(0).func_code, {}, None,
None, (cell,)
    )()

..but that's non-obvious and not particularly convenient.

Logged In: YES 
user_id=222090

I should mention the patch applies against both 2.4 and the
latest 2.5 from CVS.

Logged In: YES 
user_id=4771

I guess this can be safely sneaked in 2.5, as cells are quite undocumented internal objects anyway.  I believe it would be more natural to access the value as an attribute "c.value", though.  (Possibly even a read-write attribute?)

Probably not in 2.4, though; there is a no-new-feature policy.

Logged In: YES 
user_id=849994

Added a "cell_contents" attribute to cell objects in rev. 43131.

Logged In: YES 
user_id=31435

Jeremy, I vaguely recall that you deliberately made cell
objects non-inspectable.  Is that right?  If so and you
still care about that, note that it's no longer true.