Here's an example pasted directly from the interpreter: 
 
>>> def thread(f): 
...     """Makes sure a command spawns a thread when called.""" 
...     def newf(self, irc, msg, args, *L): 
...         ff = new.instancemethod(f, self, self.__class__) 
...         t = callbacks.CommandThread(self.callCommand, ff, irc, 
msg, args, *L) 
...         t.start() 
...     newf = new.function(newf.func_code, newf.func_globals, 
f.func_name) 
...     newf.__doc__ = f.__doc__ 
...     return newf 
... 
>>> import new 
>>> def groovy(): 
...   pass 
... 
>>> thread(groovy) 
Traceback (most recent call last): 
  File "<stdin>", line 1, in ? 
  File "<stdin>", line 7, in thread 
TypeError: arg 5 (closure) must be tuple 
 
Given that I didn't even give the (optional) arg 5, there's some bug 
here, even if it's only documentation/error message. 

Logged In: YES 
user_id=99508

Ok, I finally found my problem -- I wasn't passing the
closure=newf.func_closure argument to it.

Anyway, this is a significant documentation bug, I think --
aside from the fact that the library documentation isn't
inline with the __doc__ string, it should be documented that
the closure argument is required if the func_code depends on
a closure.

Check this out:

>>> print new.function.__doc__
function(code, globals[, name[, argdefs[, closure]]])

Create a function object from a code object and a dictionary.
The optional name string overrides the name from the code
object.
The optional argdefs tuple specifies the default argument
values.
The optional closure tuple supplies the bindings for free
variables.


Versus the library documentation:

function(  	code, globals[, name[, argdefs]])
    Returns a (Python) function with the given code and
globals. If name is given, it must be a string or None. If
it is a string, the function will have the given name,
otherwise the function name will be taken from code.co_name.
If argdefs is given, it must be a tuple and will be used to
determine the default values of parameters.

Logged In: YES 
user_id=99508

This is basically a duplicate of bug #835255, except with a
less-clear title.  I'm going to close it (I hope you don't
mind, Fred).