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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
