Unicode API naming convention

[antocuni]

Historically, Python 2 had two data types for strings:

• str to represent sequences of chars, where each char is in the range 0-255
• unicode to represent unicode strings

At the C level, the API functions related to str were called PyString_* and functions related to unicode were called PyUnicode_*.

The modern Python 3 has the same data types but with different names:

• bytes is equivalent to the old str. The C functions are called PyBytes_*
• str is equivalent to the old unicode. For the historical reasons explained above, the C functions are still called PyUnicode_*.

For HPy we have basically 3 options:

1. follow the CPython convention and call them HPyBytes_* and HPyUnicode_*
2. fix the mess and call them HPyBytes_* and HPyStr_* (or possibly HPyString_*, but I think that HPyStr is much better)
3. middle ground solution, which could be useful for other parts of the API. We could declare HPyStr_* as the official API, but also provide a separate header (maybe hpy/compat.h or hpy/cpycompat.h?) which maps HPyUnicode_* to the equivalent HPyStr_*, possibly giving a warning.

• HPyUnicode_* pros: it is easier for people to port their code from Python/C to HPy, and to compare to the CPython docs
• HPyStr_* pros: it is cleaner and more consistent with the rest of the API.

Personally, I think that the best is the middle-ground solution.

[hodgestar]

My 2c: I much prefer HPyUnicode_* and consider HPyStr_* at best confusing.

[uranusjr]

+1 to the middle ground approach, and IMO no need of a warning. A note in documentation saying Str is preferred would be enough.

[mattip]

xref #354, which leans toward HPyUnicode for easy porting of C-API functions

[fangerer]

I'll close this issue because as Matti mentioned, we decided to keep the C-level naming style (see dev call minutes)