Larry Hastings added the comment: 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24000> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
