[Python-Dev] Wild Idea for the Year

[Raymond Hettinger]

> Your idea adds some extra (constant)
> time to all string ops, and quite a bit of complexity.

It adds a single if NULL check to each op (about the same cost as
PyString_Check).

Complexity (recursive joining) is confined to a single function.
Meanwhile, the code for str.__add__() becomes simpler.  That's basically
the whole show.


> There are lots
> of places where knowledge of string internals is assumed, including
> 3rd party code using a few macros, all of which would have to be
> fixed.

Then save it for Py3.0, or not.  The idea is to make things easier for
the python programmer, beginner or pro.  With little effort on the C
side, there is an opportunity to be the first dynamic language with O(n)
behavior for serial string concatenations -- one less thing to teach,
one step towards scalability.


> But wait, I think it won't fly at all unless you make ob_sval a
> pointer to separately allocated memory.  Otherwise, how could
> _autojoin() possibly "fix" the string without allocating the memory
> for it? 

PyString_Resize().



BTW, there is a proof-of-concept demo patch with UserString at:
    www.python.org/sf/976162

Also, there is an alternative approach of having str.__add__() return a
string proxy.  This would avoid issues with 3rd party code. 

That being said, I didn't miss that you hate the idea, so I'll craft a
recipe and drop it :-(


Raymond