Repository navigation
[C API] Add PyUnicode_Equal() function #124502
Description
Activity
- added a commit that references this issue
on Sep 25, 2024 I think
PyUnicode_Equalshould likestrcmpin glibc.
Return0if a is equal to b.
Return1if a isn't equal to b.I think PyUnicode_Equal should like strcmp in glibc.
Return 0 if a is equal to b.
Return 1 if a isn't equal to b.The C API Guidelines suggest to return 1 if "found" and 0 if "not found": https://devguide.python.org/developer-workflow/c-api/#guidelines-for-expanding-changing-the-public-api
IMO it's more natural to return 1 if equal and 0 if not equal. So you can write
if (PyUnicode_Equal(a, b)) { /* a == b */ }.Moreover,
PyUnicode_Equal()API the same as existing private functions_PyUnicode_EQ()and_PyUnicode_Equal()(except that these functions don't check if arguments are strings).Reacted by Peter BiermaI think PyUnicode_Equal should like strcmp in glibc.
Return 0 if a is equal to b.
Return 1 if a isn't equal to b.
The C API Guidelines suggest to return 1 if "found" and 0 if "not found": https://devguide.python.org/developer-workflow/c-api/#guidelines-for-expanding-changing-the-public-api
IMO it's more natural to return 1 if equal and 0 if not equal. So you can write
if (PyUnicode_Equal(a, b)) { /* a == b */ }.Moreover,
PyUnicode_Equal()API the same as existing private functions_PyUnicode_EQ()and_PyUnicode_Equal()(except that these functions don't check if arguments are strings).I think that's good idea， So when will it be implemented？
Maybe you could give me a shot. HahaI already implemented the function. See attached PR.
Hmm, will this result in a cascade of
PySomething_Equalfunctions? This case should be special, I don't think we needPyLong_Equal,PyDict_Equal,PyList_Equal, etc.Out of curiosity, what's the benefit here over
PyUnicode_Compare(...) == 0?PyUnicode_Compareis slower since it needs to handle Unicode kinds separately (you need to take care of mixed kinds since comparing two Unicode strings of different kinds is a well-defined operation).PyUnicode_Equalis faster because 1) it directly usesmemcmpand 2) only needs to do something when the Unicode kinds match.Hmm, will this result in a cascade of PySomething_Equal functions? This case should be special, I don't think we need PyLong_Equal, PyDict_Equal, PyList_Equal, etc.
C extensions such as mypy and Pyodide are already using the private
_PyUnicode_EQ()function which has been removed in Python 3.13. I'm proposing a public replacement for them.I'm not aware of other PyTYPE_Equal() function. Only PyUnicode has a specialized equal function.
Out of curiosity, what's the benefit here over PyUnicode_Compare(...) == 0?
PyUnicode_Compare()returns-1for "less than" but also for the error case. The caller must callPyErr_Occurred()which is inefficient. It causes an ambiguous return value: capi-workgroup/problems#1PyUnicode_Equal()has no such ambiguous return value (-1only means error). Moreover, it may be a little bit faster, but I'm not sure about that.I'm not aware of other PyTYPE_Equal() function. Only PyUnicode has a specialize equal function.
Yeah, that's what I mean. I think it would be a bad idea to use this as precedent for future "faster"
PyXXX_Equalfunctions. I'm fine withPyUnicode_Equal.Reacted by Victor Stinner, Steve Dower and Petr ViktorinI created capi-workgroup/decisions#43 issue in the C API Working Group.
- added 7 commits that reference this issue
on Oct 7, 2024 Function added to pythoncapi-compat with change: python/pythoncapi-compat@abc0f29.
- added a commit that references this issue
on Oct 14, 2024 - added a commit that references this issue
on Oct 14, 2024
Python 3.13 moved the private _PyUnicode_EQ() function to internal C API. mypy and Pyodide are using it.
I propose to add a public PyUnicode_Equal(a, b) function to the limited C API 3.14 to replace the private _PyUnicode_EQ() function:
1if a is equal to b.0if a is not equal to b.TypeErrorexception and return-1if a or b is not a Pythonstrobject.Linked PRs