[Python-Dev] Proof of the pudding: str.partition()
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)
>> found = x.partition(sep)
>> after = x.partition(sep)
>> 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