richcompare for strings

[loewis]

BPO	424335
Nosy	@tim-one, @loewis
Files	string.patch

^{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:

assignee = 'https://github.com/loewis'
closed_at = <Date 2001-06-02.10:15:47.000>
created_at = <Date 2001-05-15.19:54:03.000>
labels = ['interpreter-core']
title = 'richcompare for strings'
updated_at = <Date 2001-06-02.10:15:47.000>
user = 'https://github.com/loewis'

bugs.python.org fields:

activity = <Date 2001-06-02.10:15:47.000>
actor = 'loewis'
assignee = 'loewis'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2001-05-15.19:54:03.000>
creator = 'loewis'
dependencies = []
files = ['3321']
hgrepos = []
issue_num = 424335
keywords = ['patch']
message_count = 6.0
messages = ['36585', '36586', '36587', '36588', '36589', '36590']
nosy_count = 2.0
nosy_names = ['tim.peters', 'loewis']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue424335'
versions = []

[loewis]

This patch implements the tp_richcompare slot for
string objects. It shows a 8% speed-up on selected test
cases.

[loewis]

Logged In: YES
user_id=21627

The new revision of the patch entirely removes tp_compare
for string, following discussions on python-dev. The only
direct user of string_compare has been changed to use the
new function _PyString_Eq instead.

[tim-one]

Logged In: YES
user_id=31435

Assigned to me.

[tim-one]

Logged In: YES
user_id=31435

Marked accepted. Looks good!

Suggest

return a->ob_size == b->ob_size &&
*a->ob_sval == *b->ob_sval &&
memcmp(a->ob_sval, b->ob_sval, a->ob_size) == 0;

for the tail of the _PyString_Eq body as compilers should
have an easier time of turning that into the best code for
the platform (especially the weaker compilers do better
optimizing expressions than across branches). Plus it
improves clarity, at least for me.

Unsure why the

case Py_EQ: c = c == 0; break; /* not needed here */

case is there: if it's truly unreacable (and I agree it
isn't), better to assert-fail if it gets there.

[tim-one]

Logged In: YES
user_id=31435

Oops! Looks like I forgot to assign this back to Martin.

[loewis]

Logged In: YES
user_id=21627

Committed as 2.117 of stringobject.c, 2.95 of
dictobject.c, and 2.27 of stringobject.h.