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/