But, aside from that, I think I would want to go much further than this _if_ I put time in redesigning PyArg_Parse. I would first like to take inventory of all the problems there are with PyArg_Parse, and then see whether we can design something that will solve most or all of these issues, without being overly complex in everyday use.
And before I embark on that journey I would first like to have a group of people willing to put effort into this, plus the go-ahead of Guido (there's little point in designing a new mechanism if there is no chance of it being adopted as the general case, especially if this new mechanism may need a new PyMethodDef flag or some such thing).
+1 on a redesign of PyArg_Parse. Though I don't want to hold up the 2.3a1 release.
As a kickoff, here are some of my gripes about PyArg_Parse.
(I can't spend too much time not paying attention to the Zope3 sprintathon, so I'll try to read these later. Chances are I agree. Surely the format characters are a big mess.) --Guido van Rossum (home page: http://www.python.org/~guido/)