[EMAIL PROTECTED] 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
_______________________________________________
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
