-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify arguments names in Unicode object C API documentation #62897
Comments
In declarations of Unicode object C API functions in Doc/c-api/unicode.rst the first Unicode object argument has different names: "unicode", "str", "u", "s". It will be good to unify these names. Of course there is no need to change reasonable argument names for such functions as PyUnicode_Concat() or PyUnicode_CopyCharacters(). |
@serhiy will you be proposing a patch for this? |
No, I am not. I have no opinion what name is better. |
The same issue exists for other types. E.g. PyLong_* functions have Python long argument named as p, obj and pylong, PyFloat_* -- p and pyfloat, PyList_* -- p and list, PyDict_* -- p, a and mapping, PyBytes_* -- o, obj, string and bytes. |
Just checking, it would be required to update Objects/unicodeobject.c, Include/unicodeobject.h, and Doc/c-api/unicode.rst, right? As far as I saw, "unicode" means a Python object with unicode string, "u" is a UTF-8 encoded C string, "str" and "s" are encoded C strings (UTF-8, UTF-7, ASCII, Latin-1, among others). Is it alright to rename Python unicode objects to "unicode" and the others to simply "str"? These names are more meaningful than the single character alternatives. The same logic would be applied to the other types, always keeping the longer name rather than the single character ones. |
I agreed with @matheus, it would be better than the current implementation |
I have some interest in making a fix for this. From discussion, I'm thinking that, barring names that already have clear meaning (EG, left/right for things with two parameters):
Those seem to be the intersect of most common and most descriptive names already seen. |
Another inconsistency I've noticed is that the code sometimes refers to Py_ssize_t instances as a 'length' and sometimes as a 'size'. It seems like 'size' is the more common one in the docs, but the headers more often use 'length'. Which would be the better one to keep for the common case? |
It has been over a month and I'm still waiting for an updated PR review. I understand if people are busy, but don't want this to just fall through the cracks. |
Standardize PyUnicode C API parameter names across the documentation. Co-authored-by: Serhiy Storchaka <[email protected]>
…GH-12680) Standardize PyUnicode C API parameter names across the documentation. (cherry picked from commit b31232d) Co-authored-by: Rune Tynan <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…GH-12680) Standardize PyUnicode C API parameter names across the documentation. (cherry picked from commit b31232d) Co-authored-by: Rune Tynan <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…H-112744) Standardize PyUnicode C API parameter names across the documentation. (cherry picked from commit b31232d) Co-authored-by: Rune Tynan <[email protected]>
…H-112745) Standardize PyUnicode C API parameter names across the documentation. (cherry picked from commit b31232d) Co-authored-by: Rune Tynan <[email protected]>
Standardize PyUnicode C API parameter names across the documentation. Co-authored-by: Serhiy Storchaka <[email protected]>
Standardize PyUnicode C API parameter names across the documentation. Co-authored-by: Serhiy Storchaka <[email protected]>
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: