Here's another siy idea, not having to do with optimization. On the Mac, and as far as I know on Windows as well, there are quite a few OS API structures that have a Python Object representation that is little more than the PyObject boilerplate plus a pointer to the C API object. (And, of course, lots of methods to operate on the object). To convert these from Python to C I always use boilerplate code like WindowPtr *win; PyArg_ParseTuple(args, "O&", PyWin_Convert, &win); where PyWin_Convert is the function that takes a PyObject * and a void **, does the typecheck and sets the pointer. A similar way is used to convert C pointers back to Python objects in Py_BuildValue. What I was thinking is that it would be nice (if you are _very_ careful) if this functionality was available in struct. So, if I would somehow obtain (in a Python string) a C structure that contained, say, a WindowPtr and two ints, I would be able to say win, x, y = struct.unpack("Ohh", Win.WindowType) and struct would be able, through the WindowType type object, to get at the PyWin_Convert and PyWin_New functions. A nice side issue is that you can add an option to PyArg_Parsetuple so you can say PyArg_ParseTuple(args, "O+", Win_WinObject, &win) and you don't have to remember the different names the various types use for their conversion routines. Is this worth pursuing is is it just too dangerous? And, if it is worth pursuing, I have to stash away the two function pointers somewhere in the TypeObject, should I grab one of the tp_xxx fields for this or is there a better place? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm