It's a bit more complex, it's implementation-specific, it's definitely a hack and it's not very reliable:
* It's a CPython-only optimization
* It does not work if the first member of the concatenation is an interned string (such as a literal string, so `s = s + "abc"` may trigger the optimization but `s = "abc" + s` will never do so)
* It only works if there's a single reference to the string in the system.
* It only works for the shapes `s = s + s1` and `s += s1` and no other[0], including (excluding?) `s = s + s1 + s2` or `someFunction(s + s1)`
The way it works is that, when it sees `s = s + "abc"` or `s += "abc"` and there's a single reference to `s` (this one), CPython will call `realloc(3)` on the string's internal buffer (technically it calls `_PyString_Resize` which calls `PyObject_Realloc` unless you've compiled python --without-pymalloc then it calls a macro over realloc(3), but you get the point) instead of allocating a brand new string. And it does not work on unicode objects in CPython 2 (only str, it works on both str and bytes in CPython 3).
Interestingly, this optimization was introduced by Armin Rigo[1], one of the lead Pypy devs for which this CPython optimization is an issue (it leads developers to use more string concatenation, which pypy can not really optimize as it does not use refcounting semantics)[2]
PS: I don't think I've noted how much HN's comment-editing "facilities" suck today. They really, really suck. What's a man got to do for markdown support in order to make formatted comments readable?
You could hack markdown support into the HN code base. It's open source. And once you've written it, you should have a decent chance of lobbying for its inclusion into the copy running news.ycombinator.com
Why would the austerity of current support hinder his lobbying efforts for his improved version? If compatibility is a problem, you can just run comments before flag day through the old code. Or write a converter.
You are thinking about HN as if it was just a piece of software. It isn't just a piece of software; it's also:
* an important piece of YC's infrastructure, so it doesn't have a normal dev team; some of the data going through HN is "hazmat".
* a demonstration of a new programming language Graham is ostensibly working on, which implies that doing things "the right way" is more important than on a typical project.
* in part a secret (the published HN code is not the code running on HN).
* It's a CPython-only optimization
* It does not work if the first member of the concatenation is an interned string (such as a literal string, so `s = s + "abc"` may trigger the optimization but `s = "abc" + s` will never do so)
* It only works if there's a single reference to the string in the system.
* It only works for the shapes `s = s + s1` and `s += s1` and no other[0], including (excluding?) `s = s + s1 + s2` or `someFunction(s + s1)`
The way it works is that, when it sees `s = s + "abc"` or `s += "abc"` and there's a single reference to `s` (this one), CPython will call `realloc(3)` on the string's internal buffer (technically it calls `_PyString_Resize` which calls `PyObject_Realloc` unless you've compiled python --without-pymalloc then it calls a macro over realloc(3), but you get the point) instead of allocating a brand new string. And it does not work on unicode objects in CPython 2 (only str, it works on both str and bytes in CPython 3).
Interestingly, this optimization was introduced by Armin Rigo[1], one of the lead Pypy devs for which this CPython optimization is an issue (it leads developers to use more string concatenation, which pypy can not really optimize as it does not use refcounting semantics)[2]
[0] http://bugs.python.org/issue980695#msg46258
[1] http://bugs.python.org/issue980695
[2] https://bugs.pypy.org/issue814 (nb: pypy's bug tracker displays the oldest comment at the bottom)
PS: I don't think I've noted how much HN's comment-editing "facilities" suck today. They really, really suck. What's a man got to do for markdown support in order to make formatted comments readable?