Return new string for single subclass joins (Bug #1001011)

[ncoghlan]

BPO	1007087
Nosy	@tim-one, @rhettinger, @ncoghlan
Files	str_join2.diff: Fix that preserves optimisation for the two builtin classes

^{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 = None
closed_at = <Date 2004-08-23.23:26:54.000>
created_at = <Date 2004-08-11.08:03:32.000>
labels = ['interpreter-core']
title = 'Return new string for single subclass joins (Bug python/cpython#40662)'
updated_at = <Date 2004-08-23.23:26:54.000>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2004-08-23.23:26:54.000>
actor = 'rhettinger'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-08-11.08:03:32.000>
creator = 'ncoghlan'
dependencies = []
files = ['6176']
hgrepos = []
issue_num = 1007087
keywords = ['patch']
message_count = 8.0
messages = ['46667', '46668', '46669', '46670', '46671', '46672', '46673', '46674']
nosy_count = 3.0
nosy_names = ['tim.peters', 'rhettinger', 'ncoghlan']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1007087'
versions = ['Python 2.4']

[ncoghlan]

At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

[tim-one]

Logged In: YES
user_id=31435

This is an important optimization for "true strings". It was
indeed the intent that internal optimization for immutable
types not be applied to subclass instances, so it's good to fix
that. It's not good to lose the optimization when it's safe.

[ncoghlan]

Logged In: YES
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

[ncoghlan]

Logged In: YES
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

[ncoghlan]

Logged In: YES
user_id=1038590

Oh - the test looks explicitly for the optimised behaviour
for a true string (to make sure this version preserved that
behaviour). Is that a good idea, or not?

[rhettinger]

Logged In: YES
user_id=80475

The patch looks good, it compiles okay, and the test_suite
passes.

If Tim has no further issues, I will apply it.

[tim-one]

Logged In: YES
user_id=31435

Unassigned myself -- can't make time for this now.

[rhettinger]

Logged In: YES
user_id=80475

Applied as:
Objects/stringobject.c 2.225
Lib/test/test_string.py 1.26

Thanks for the perfect patch.