PyLong and PyUnicode don't match the Python type names

[encukou]

No description provided.

[gvanrossum]

Could be solved with a (large) number of macros. But is it worth the churn? Over time, naming never remains fully consistent.

[encukou]

IMO, it's not worth the churn at all. But I have seen people trying to name new APIs with Int/Str prefixes. What to do there? IMO, we should be consistent with the existing names, unless we're overhauling all of the API.

cc @markshannon

Full disclosure: I maintain a Python 2/3 compat library that does stuff like alias PyInt_* to PyLong_*, which is technically abuse of the reserved Py namespace. But I don't think I'm the only one doing that.

[markshannon]

I agree it isn't worth the churn to change the current API, but it does provide a way to distinguish between old API (Long/Unicode) and new API (Int/Str) should we add a new API.

[serhiy-storchaka]

What is this new APIs with Int/Str prefixes? "Int" means "related to C int", "String" means "related to C char *". Having names with "Str" and "String" with very different meaning would confuse.

[markshannon]

Would it be that confusing?

Using Int to refer to the Python type is less confusing than Long. Only C has a long type, Python doesn't.

[encukou]

Guideline issue, where I propose to keep the old/consistent names: capi-workgroup/api-evolution#23