Re: [Python-Dev] Proof of the pudding: str.partition()
I once wrote a similar method called cleave(). My use case involved a string-like class (Substr) whose instances could report their position in the original string. The re module wasn't preserving my class so I had to provide a different API. def cleave(self, pattern, start=0): """return Substr until match, match, Substr after match If there is no match, return Substr, None, '' """ Here are some observations/questions on Raymond's partition() idea. First of all, partition() is a much better name than cleave()! Substr didn't copy as partition() will have to, won't many of uses of partition() end up being O(N^2)? One way that gives the programmer a way avoid the copying would be to provide a string method findspan(). findspan() would returns the start and end of the found position in the string. start > end could signal no match; and since 0-character strings are disallowed in partition, end == 0 could also signal no match. partition() could be defined in terms of findspan(): start, end = s.findspan(sep) before, sep, after = s[:start], s[start:end], s[end:] Just a quick thought, -Tony
tony@lownds.com wrote:
Substr didn't copy as partition() will have to, won't many of uses of partition() end up being O(N^2)?
Yes. But if you look at most cases provided for in the standard library, that isn't an issue. In the case where it becomes an issue, it is generally because a user wants to do repeated splitting on the same token...which is better suited for str.split or re.split.
One way that gives the programmer a way avoid the copying would be to provide a string method findspan(). findspan() would returns the start and end of the found position in the string. start > end could signal no match; and since 0-character strings are disallowed in partition, end == 0 could also signal no match. partition() could be defined in terms of findspan():
start, end = s.findspan(sep) before, sep, after = s[:start], s[start:end], s[end:]
Actually no. When str.parition() doesn't find the separator, you get s, '', ''. Yours would produce '', '', s. On not found, you would need to use start==end==len(s). Further, findspan could be defined in terms of find... def findspan(s, sep): if len(sep) == 0: raise ValueError("null separator strings are not allowed") x = s.find(sep) if x >= 0: return x, x+len(sep) return len(s),len(s) Conceptually they are all the same. The trick with partition is that in the vast majority of use cases, one wants 2 or 3 of the resulting strings, and constructing the strings in the C-level code is far faster than manually slicing (which can be error prone). I will say the same thing that I've said at least three times already (with a bit of an expansion): IF YOU ARE GOING TO PROPOSE AN ALTERNATIVE, SHOW SOME COMPARATIVE CODE SAMPLES WHERE YOUR PROPOSAL DEFINITELY WINS OVER BOTH str.find AND str.partition. IF YOU CAN'T PROVIDE SUCH SAMPLES, THEN YOUR PROPOSAL ISN'T BETTER, AND YOU PROBABLY SHOULDN'T PROPOSE IT. bonus points for those who take the time to compare all of those that Raymond provided. - Josiah
Actually no. When str.parition() doesn't find the separator, you get s, '', ''. Yours would produce '', '', s. On not found, you would need to use start==end==len(s).
You're right. Nevermind, then.
I will say the same thing that I've said at least three times already (with a bit of an expansion):
Thanks for the re-re-emphasis. -Tony
participants (2)
-
Josiah Carlson -
tony＠lownds.com