__code__ and __closure__ are designed to work together.  There is no point in allowing to completely substitute the __code__ object, but protecting the __closure__.

Updated patch as per Andrew's code review.  Thank you.

Please update the doc also. I think changing from 'Read-only' to 'Writable' in Doc/reference/datamodel.rst is enough.

> Please update the doc also. I think changing from 'Read-only' to 'Writable' in Doc/reference/datamodel.rst is enough.

Updated in writable_closure_03.patch.  Thanks.

Updated patch per Benjamin's review. See writable_closure_04.patch.

Another use case for a writeable __closure__ attribute is to make it possible to manually break reference cycles:
http://blog.ccpgames.com/kristjan/2012/04/23/reference-cycles-with-closures/

Shouldn't test___closure__() also test what happens when the closure is replaced with None, or a tuple which is too long or too short or contains non-cell objects?

All of these things seem to be checked when you create a new function using types.FunctionType:

>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: arg 5 (closure) must be tuple
>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, ())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: g requires closure of length 2, not 0
>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, (1,2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: arg 5 (closure) expected cell, found int

I think the setter should make similar checks.  Maybe there is C code which assumes "broken" closures never happen.

The patch causes crashes.  If I define

  def cell(o):
    def f(): o
    return f.__closure__[0]

  def f():
    a = 1
    b = 2
    def g():
      return a + b
    return g

  g = f()

then I find

  g.__closure__ = None; g()                          -> crash
  g.__closure__ = (cell(3),); g()                    -> crash
  g.__closure__ = (1, 2); g()                        -> SystemError *
  g.__closure__ = (cell(3), cell(4), cell(5)); g()   -> returns 7

* SystemError: ..\Objects\cellobject.c:24: bad argument to internal function

> The patch causes crashes.

Yes, that's known.  

First, we need to check, that we can only write tuple of cell objects or None in __closure__ (that's easy to add).  Secondly, perhaps, we can check __closure__ correctness each time we start evaluating a code object.  The latter would offer us better stability, but may also introduce some slowdowns -- need to find some time to implement and benchmark this.

Version of patch which checks invariants in the setter and adds tests.

sbt, looks good for me.