My approach to the fix (from an email sent to svdlinden last week)

1) gjs doesn't seem to have any real callback support (only closures
and .connect())
2) seed does, and thankfully it looks like its very similar to pygi
and I may be able to use a lot of the ideas from it.  In particular:
3) seed uses libffi which to me seems required. 
4) It looks like the libffi method of implementing callbacks leaks
some memory when closures are created.  This seems fundamentally
unavoidable and something we might have to live with.  (PyGI does not
know when to free the closure as the C code could call the callback
again in the future, we don't know when they let it go)

My attack plan is to

1)  in pygi-arguement.c around line ~960 insert some code very similar
to seed_make_native_closure() which builds an ffi closure via some
gobject-introspection library magic, packs it with a bunch of private
user data (including type info from the GIR and a pointer to the real
python callback function) into some sort of PyGINativeClosure struct
and returns that as the data pointer.  The closure itself, when called
(via ffi stack smashing magic), points to 2)

2) a new function which is the new "callback" (created by the libffi
magic) which takes the c arguements and converts them to PyObjects
(using GIR type data from userdata) and then calls the real python
function (stored previously in the userdata).



Current Status:
Using the seed code as a model there is a fully functional prototype implemented at http://github.com/ZachGoldberg/pygi-callbacks .  TO DO:
1) a whole bunch of bounds checking
2) memory cleanups 
3) unit tests.

*** This bug has been marked as a duplicate of bug 603095 ***