[Python-Dev] Proof of the pudding: str.partition()
Phillip J. Eby
pje at telecommunity.com
Wed Aug 31 15:40:15 CEST 2005
At 04:55 AM 8/31/2005 -0700, Michael Chermside wrote:
>Raymond's original definition for partition() did NOT support any
>of the following:
>
> (*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
> (*) Ways to generate just 1 or 2 of the 3 values if some are
> not going to be used
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.
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.
> (*) Clever use of indices to avoid copying strings
> (*) Behind-the-scenes tricks to allow repeated re-partitioning
> to be faster than O(n^2)
Yep, -1 on these.
>The absence of these "features" is a GOOD thing. It makes the
>behavior of partition() so simple and straightforward that it is
>easily documented and can be instantly understood by a competent
>programmer. I *like* keeping it simple. In fact, if anything, I'd
>give UP the one fancy feature he chose to include:
>
> (*) An rpartition() function that searches from the right
>
>...except that I understand why he included it and am convinced
>by the arguments (use cases can be demonstrated and people would
>expect it to be there and complain if it weren't).
I'd definitely like to keep rpartition. For example, splitting an HTTP
url's hostname from its port should be done with rpartition, since you can
have a 'username:password@' part before the host, and because the host can
be a bracketed bracketed IPv6 host address with colons in it.
>Simplicity and elegence are two of the reasons that this is such
>an excellent proposal,
+1.
More information about the Python-Dev
mailing list