I have no interest in naming "str" to "pchar".

Yes, *most* of the other converters are named after the C type they translate to.  But so far converter names doesn't mention whether or not they represent pointers to types--it's "object", not "pobject", it's "PyBytesObject", not "pPyBytesObject".  That suggests the name "char" for the converter.  But we've already got a "char", and it would be confusing to use that one converter for both chars (small ints / single characters) and strings.

Adding "p" in front is not a convention we've ever used.  The word "pchar" does not appear in the Python source tree.  So the name "pchar" has no mnemonic value.

If I were to follow your advice, I should prefer the name "char_star".  But now we're using nine letters for what is almost certainly the most common converter.  And, again, the generic converter for objects is called "object", I do not propose to rename it to "object_star".  So this converter's name would be an exception to the rule.

But then again, C strings themselves are an exception to the rule.  They're not a built-in type as much as they are a *convention*.  So any name we give it will ultimately be something of a compromise.  And as compromises go "str" is great.  So far nobody has been confused by it.  It's short, and universally, instantly clear as to its meaning.

Furthermore, converters don't actually represent a C type.  They represent a *mapping*, from a Python type (or types) to a single C type.  So while it's a useful and productive convention to name converters after the type they convert to, it's hardly mandatory.  And it would be a shame to squander clarity in service to a needless consistency.

p.s. If we hold ourselves to this firm ideal, where every converter is named after its C type, what should we call the "bool" converter?  What should we call the "self" converter?  What should you call your proposed "boolint" converter?