[Python-Dev] Proof of the pudding: str.partition()

Steve Holden steve at holdenweb.com
Wed Aug 31 23:51:14 CEST 2005

Fredrik Lundh wrote:
> Phillip J. Eby wrote:
>>Yep, subscripting and slicing are more than adequate to handle *all* of
>>those use cases, even the ones that some people have been jumping through
>>odd hoops to express:
>>    before = x.partition(sep)[0]
>>    found  = x.partition(sep)[1]
>>    after  = x.partition(sep)[2]
>>    before, found = x.partition("foo")[:2]
>>    found,  after = x.partition("foo")[1:]
>>    before, after = x.partition("foo")[::2]
>>Okay, that last one is maybe a little too clever.  I'd personally just use
>>'__' or 'DONTCARE' or something like that for the value(s) I didn't care
>>about, because it  actually takes slightly less time to unpack a 3-tuple
>>into three function-local variables than it does to pull out a single
>>element of the tuple, and it's almost twice as fast as taking a slice and
>>unpacking it into two variables.
> you're completely missing the point.
> the problem isn't the time it takes to unpack the return value, the problem is that
> it takes time to create the substrings that you don't need.
Indeed, and therefore the performance of rpartition is likely to get 
worse as the length of the input strung increases. I don't like to think 
about all those strings being created just to be garbage-collected. Pity 
the poor CPU ... :-)

> for some use cases, a naive partition-based solution is going to be a lot slower
> than the old find+slice approach, no matter how you slice, index, or unpack the
> return value.
Yup. Then it gets down to statistical arguments about the distribution 
of use cases and input lengths. If we had a type that represented a 
substring of an existing string it might avoid the stress, but I'm not 
sure I see that one flying.

>>So, using three variables is both faster *and* easier to read than any of
>>the variations anybody has proposed, including the ones I just showed above.
> try again.
The collective brainpower that's been exercised on this one enhancement 
already must be phenomenal, but the proposal still isn't perfect.

Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/

More information about the Python-Dev mailing list