[Python-Dev] Wild Idea for the Year
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
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