[Python-Dev] Wild Idea for the Year

Raymond Hettinger python at rcn.com
Wed Jun 23 13:52:35 EDT 2004

> 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

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? 


BTW, there is a proof-of-concept demo patch with UserString at:

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 :-(


More information about the Python-Dev mailing list