Hmm. I think that having separate PyArg_ParseTuple and PyArg_UncheckedParseTuple is absolute overkill. Also, I think the functionality of having the checks is a fine one, I was at the time grumbling about it being a backward-incompatible change, and moreover one that caused me a lot of work at a time that I had more than enough other things to do. But now that the work is done I see no reason to revert it. If we'd want to do a complete set of arguments for each of 8, 16 and 32 bit integers we would have 3 specifiers: signed, unsigned and bitpattern. As it stands now we have: signed unsign bitpattern 8bit - b - 16bit h H - 32bit - - l (note the last one: 32bit values are in essence not checked because the parser happily stuffs 0xffffffff into a long). What I would be happy with is to have "natural" (unsigned for char, signed for other types) and bitpattern, so natural bitpattern 8bit b B 16bit h H 32bit l L I agree about breaking L: it's there but in the standard distribution it isn't used a single time. -- 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