This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Deferred String Addtion: Proof-of-concept
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, jimjjewett, rhettinger
Priority: low Keywords: patch

Created on 2004-06-20 10:10 by rhettinger, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
defstr.diff rhettinger, 2004-06-20 10:10 Patch to UserString.py
Messages (4)
msg46198 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-06-20 10:10
The attached patch demonstrats a possible
implementation for 
deferred string addition.  The idea is to have
str.__add__ save references to its inputs rather that
do the concatenation immediately.  The moment some
other method needs the full string, it is generated
recursively so that the whole concatenation can be done
with a single join.

msg46199 - (view) Author: Jim Jewett (jimjjewett) Date: 2004-06-21 14:31
Logged In: YES 
user_id=764593

There is an implicit assumption that any component/part with 
its own 'components' attribute will be another UserString (or, 
at the very least, will act like one when traversed).

Would it be better to check whether the subobject actually is 
a UserString (since new-style objects can freely use multiple 
inheritance), or to do some sort of guard in add?  (Perhaps 
immediately stringifying anything with a components attribute 
that is not a UserString?)
msg46200 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-06-22 04:28
Logged In: YES 
user_id=80475

The patch is not meant to be loaded to UserString.  Rather
it is a proof-of-concept demonstration of how deferred
string addition would work. Even it pure python form, it
shows how to convert an O(n**2) process to O(n).  If the
concept is approved, the goal is to alter the C code for
stringobject.c, unicodeobject.c, and to make a more thorough
version for UserString.
msg46201 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2004-07-28 03:19
Logged In: YES 
user_id=6380

Nice to have this, but no point in keeping it open forever -- it 
will never be applied.
History
Date User Action Args
2022-04-11 14:56:04adminsetgithub: 40422
2004-06-20 10:10:22rhettingercreate