[issue1569040] Speed up using + for string concatenation
Ramchandra Apte added the comment: Buuump. -- nosy: +ramchandra.apte ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Benjamin Peterson added the comment: This issue hasn't been touched in years and would certainly need a completely new patch. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: IIRC, this has already been rejected on python-dev in a number of discussions (check for ropes in the search). Also, Armin has long ago implemented some optimizations for string concatenation in a number of contexts. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Larry Hastings la...@hastings.org added the comment: rhettinger: It's a bit unfair to paint the lazy string concatenation patch with the adjective ropes, then point out ropes have been rejected many times. Lazy string concatenation objects are a form of specialized rope but they don't share the downsides of these other ropes proposals. The major problems with conventional rope implementations are a) slowdown, b) complexity, and c) you must use a new API to interact with them: http://mail.python.org/pipermail/python-dev/2000-February/002321.html Lazy string concatenation makes Python faster, it isolates its complexity locally inside the string object implementation, and it makes only two changes to the API. Those two changes are: one, you may no longer access the string directly, and two, APIs that returned the internal string (PyString_AsString, PyString_AS_STRING*) may fail in low-memory conditions. You don't need to use a new API to interact with the string; traditional APIs like strchr work fine. * Those were the names in 2.6 anyway. I don't know what the modern names would be in 3.1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I think lazy evaluation was discussed in the same thread. Either I or someone else suggested it and there was some issue because the string struct had long been exposed and people were accessing it directly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Larry Hastings la...@hastings.org added the comment: Thanks for pointing that out! I think I found it; the discussion is actually about lazy string slices, and it starts here: http://mail.python.org/pipermail/python-dev/2000-February/002317.html If I were to resubmit lazy string slices (which wouldn't be in this patch), the slices would only have weakrefs on the original string and render when the original string was destroyed. That addresses some of the concerns about lazy string slices, though they are still uncomfortably (internally) complex. As for the second concern: the official way is to use the accessors, and CPython consistently uses them itself. I don't know what the right answer is. We *could* make PyStringObject a private type to force the issue, though that would add overhead. (Well, PyUnicodeObject really, this would never be accepted in the 2.x series at this point.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Benjamin Peterson benja...@python.org added the comment: In that case, I think it's probably ok to reopen until we have a more definite accept or reject. -- resolution: rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Antoine Pitrou pit...@free.fr added the comment: For information, I haven't done any benchmarks, but the StringIO type in Python 3.1 should be very efficient for this kind of purposes. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Daniel Diniz aja...@gmail.com added the comment: IIRC, this was rejected as part of a larger string views proposal. Leaving open so that current performance optimizers can take a look at this :) -- nosy: +ajaksu2 priority: normal - low type: - performance versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Benjamin Peterson benja...@python.org added the comment: I'm rejecting this because previous string views have been rejected. -- nosy: +benjamin.peterson resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569040] Speed up using + for string concatenation
Larry Hastings la...@hastings.org added the comment: I'm not saying that killing a two-year-old DOA patch is the wrong move--though I hold out hope that lazy string concatenation in CPython will yet happen. But you shouldn't kill this patch just because you think it has something to do with string views--it doesn't. String views were suggested by Josiah Carlson. A string view was a separate object with a reference to a string (or strings); this patch changed the implementation of strings directly. Josiah Carlson would be the first to point out that lazy strings and string views were different: http://mail.python.org/pipermail/python-3000/2007-January/005546.html Here's my take on what happened with lazy string concatenation. GvR asked me to port it to Py3k. I optimistically combined lazy string concatenation with another optimization, lazy string slices, and submitted the combined patch. GvR examined the two patches together and disliked it because of the behavior of the lazy string slices. http://bugs.python.org/issue1629305 I subsequently tried to drum up interest in lazy concatenation without lazy string slices: http://mail.python.org/pipermail/python-3000/2007-January/005641.html but there was no strong interest. Finally, GvR officially rejected the patch. I hold out hope that lazy string concatenation, separate from lazy string slices, could still make it in. (Truthfully, I hope they *both* could make it in someday, if I did a better job.) I wouldn't claim these are a no-brainer--see my original description of the patch for caveats--but I still think they're worth the tradeoffs. FWIW, ajaksu2, another implementations of Python *has* already implemented this approach: PyPy. http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html#string-join-objects Writing for the sake of posterity, /larry/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1569040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
