Title: Move eq.h out of stringlib
Type: enhancement Stage: resolved
Components: Interpreter Core, Unicode Versions: Python 3.11
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: ezio.melotti, iritkatriel, rhettinger, serhiy.storchaka, thatiparthy, vstinner
Priority: normal Keywords: easy (C)

Created on 2012-10-25 09:29 by serhiy.storchaka, last changed 2021-07-08 19:35 by rhettinger. This issue is now closed.

File name Uploaded Description Edit
16321.patch moijes12, 2013-03-07 09:33 review
Messages (7)
msg173749 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-10-25 09:29
The Objects/stringlib directory used for "templates" which instantiates for specified bytes or unicode kinds. Objects/stringlib/eq.h has no relation to this "templates" and should be moved out (as Objects/unicode_eq.h for example).

Also it should be removed from Include/Python.h. It used only in Objects/dictobject.c and Objects/setobject.c, and included there directly.
msg183646 - (view) Author: moijes12 (moijes12) Date: 2013-03-07 09:33
Changes made according to the Sehiy's last comment. Include/Python.h has not been modified as it doesn't need one. Also, make files have been changed.
msg183720 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-03-08 01:42
I don't understand why do we have specialized functions to compare strings. Can't we reuse PyUnicode_Compare(a, b) or PyUnicode_RichCompare( a, b, Py_EQ)? Is unicode_eq() used to inline the code?

By the way, unicode_compare_eq() (subfunction of these functions) and unicode_eq() have a different implementation. unicode_eq() checks the first byte before calling memcmp(). We should only have one implementation, the fastest if possible :-)

See also issue #16286.
msg185971 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-04-03 22:11
Issue #17628 proposes a patch which reuses unicode_eq() in PyUnicode_RichCompare.
msg396223 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-06-21 10:33
Some of this cleanup was done but we still have unicode_eq in Objects/stringlib/eq.h which is only used in Objects/dictobject.c.
msg397036 - (view) Author: Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) (thatiparthy) * Date: 2021-07-06 10:47
To add irit's comment, It is *also* used in Objects/unicodeobject.c
msg397166 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2021-07-08 19:35
The remaining unicode_eq can be left as-is.   While it is only in dictobject.c, the requisite knowledge of string internals makes it reasonable to keep it in stringlib.
Date User Action Args
2021-07-08 19:35:43rhettingersetstatus: open -> closed
resolution: fixed
messages: + msg397166

stage: needs patch -> resolved
2021-07-06 10:47:06thatiparthysetnosy: + thatiparthy
messages: + msg397036
2021-06-21 10:33:34iritkatrielsetversions: + Python 3.11, - Python 3.4
nosy: + iritkatriel

messages: + msg396223

keywords: + easy (C), - patch
2014-01-05 05:32:00moijes12setnosy: - moijes12
2013-04-03 22:11:25vstinnersetmessages: + msg185971
2013-03-11 16:30:38serhiy.storchakasetnosy: + rhettinger
2013-03-08 01:42:58vstinnersetmessages: + msg183720
2013-03-07 09:33:02moijes12setfiles: + 16321.patch

nosy: + moijes12
messages: + msg183646

keywords: + patch
2012-10-25 09:29:39serhiy.storchakacreate