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

[Steve Holden]

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.

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