Of course, after I added the H specifier to PyArg_ParseTuple it turns out that solved ninetysomething% of my problems, but it turns out that what I really need is not an "unsigned short" converter but a "16 bit" converter, i.e. something that will happily accept anything from -32768 to 65535 without complaints. (The old "h" format, in other words). I need this because all the MacOS API modules are machine generated, both the C modules and the .py files with all the constants in it, and some header file authors use -1 to mean "16 1 bits", some use 0xffff. And I really don't want to hand-massage 40K lines of C and 6K lines of Python everytime a new MacOS release comes out.... And I also need such a format char for 8 bit values. Does anyone mind if I change the H specifier to do no value checking other than making sure it fits in 16 bits, and add a B specifier for unchecked bytes? -- 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/ ++++