[Python-Dev] The "lazy strings" patch

"Martin v. Löwis" martin at v.loewis.de
Tue Oct 24 00:11:04 CEST 2006

skip at pobox.com schrieb:
>     >> 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. 
> Come on Martin.  Give Larry a break.

I'm seriously not complaining, I'm explaining.

> Lots of changes have been accepted to
> to the Python core which weren't obvious "bug fixes".

Surely many new features have been implemented over time, but in many
cases, they weren't really "big changes", in the sense that you could
ignore them if you don't like them. This wouldn't be so in this case:
as the string type is very fundamental, people feel a higher interest
in its implementation.

> In fact, I seem to
> recall a sprint held recently in Reykjavik where the whole point was just to
> make Python faster.

That's true. I also recall there were serious complaints about the
outcome of this sprint, and the changes to the struct module in
particular. Still, the struct module is of lesser importance than
the string type, so the concerns were smaller.

> 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.

Have you reviewed the patch and can vouch for its correctness, even in
boundary cases? Have you tested it in a real application and found
a real performance improvement? I have done neither, so I can't speak
on the advantages of the patch. I didn't actually object to the
inclusion of the patch, either. I was merely stating what I think
the problems with "that kind of" patch are.


More information about the Python-Dev mailing list