[Python-Dev] The "lazy strings" patch

Steve Holden steve at holdenweb.com
Mon Oct 23 15:51:35 CEST 2006

skip at pobox.com wrote:
>     >> Anyway, it was my intent to post the patch and see what happened.
>     >> Being a first-timer at this, and not having even read the core
>     >> development mailing lists for very long, I had no idea what to
>     >> expect.  Though I genuinely didn't expect it to be this brusque.
>     Martin> I could have told you :-) The "problem" really is that you are
>     Martin> suggesting a major, significant change to the implementation of
>     Martin> Python, and one that doesn't fix an obvious bug. 
The "obvious bug" that it fixes is slowness <0.75 wink>.

> Come on Martin.  Give Larry a break.  Lots of changes have been accepted to
> to the Python core which weren't obvious "bug fixes".  In fact, I seem to
> recall a sprint held recently in Reykjavik where the whole point was just to
> make Python faster.  I believe that was exactly Larry's point in posting the
> patch.  The "one obvious way to do" concatenation and slicing for one of the
> most heavily used types in python appears to be faster.  That seems like a
> win to me.
I did point out to Larry when he went to c.l.py with the original patch 
that he would face resistance, so this hasn't blind-sided him. But it 
seems to me that the only major issue is the inability to provide 
zero-byte terminators with this new representation.

Because Larry's proposal for handling this involves the introduction of 
a new API that can't already be in use in extensions it's obviously the 
extension writers who would be given most problems by this patch.

I can understand resistance on that score, and I could understand 
resistance if there were other clear disadvantages to its 
implementation, but in their absence it seems like the extension modules 
are the killers.

If there were any reliable way to make sure these objects never got 
passed to extension modules then I'd say "go for it". Without that it 
does seem like a potentially widespread change to the C API that could 
affect much code outside the interpreter. This is a great shame. I think 
Larry showed inventiveness and tenacity to get this far, and deserves 
credit for his achievements no matter whether or not they get into the core.

Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb       http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden

More information about the Python-Dev mailing list